perm filename CLWIND.MSG[COM,LSP]46 blob
sn#879069 filedate 1989-11-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00215 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00028 00002
C00029 00003 ∂02-Jan-88 1049 CL-Windows-mailer gcontext-function
C00030 00004 ∂04-Jan-88 0146 CL-Windows-mailer more clx questions
C00033 00005 ∂04-Jan-88 1144 CL-Windows-mailer Comments on CLUE
C00041 00006 ∂04-Jan-88 1516 CL-Windows-mailer CLX server extension facilities
C00049 00007 ∂05-Jan-88 1006 CL-Windows-mailer Re: CLX server extension facilities
C00053 00008 ∂05-Jan-88 1551 CL-Windows-mailer more clx questions
C00057 00009 ∂06-Jan-88 1524 CL-Windows-mailer Re: CLX question
C00060 00010 ∂06-Jan-88 2216 CL-Windows-mailer object oriented CLX patches
C00072 00011 ∂07-Jan-88 1316 CL-Windows-mailer proposed C Xlib changes that CLX should mimic
C00084 00012 ∂07-Jan-88 1410 CL-Windows-mailer Re: more clx questions
C00093 00013 ∂07-Jan-88 1436 CL-Windows-mailer Re: more clx questions
C00098 00014 ∂12-Jan-88 1023 CL-Windows-mailer Change of address
C00100 00015 ∂15-Jan-88 0833 CL-Windows-mailer CLX child coordinate bug
C00104 00016 ∂18-Jan-88 2101 CL-Windows-mailer help for LISP on SUNs
C00106 00017 ∂19-Jan-88 1016 CL-Windows-mailer Re: Post conference reflection - object-oriented toolkit
C00111 00018 ∂19-Jan-88 1125 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
C00121 00019 ∂19-Jan-88 1217 CL-Windows-mailer help for LISP on SUNs
C00123 00020 ∂19-Jan-88 2115 CL-Windows-mailer CLX :force-output-p and event-listen
C00127 00021 ∂20-Jan-88 0805 CL-Windows-mailer CLX questions
C00130 00022 ∂21-Jan-88 1851 CL-Windows-mailer Re: CLX :force-output-p and event-listen
C00132 00023 ∂22-Jan-88 1644 CL-Windows-mailer Re: CLX :force-output-p and event-listen
C00138 00024 ∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
C00141 00025 ∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
C00144 00026 ∂23-Jan-88 0828 CL-Windows-mailer CLX :force-output-p and event-listen
C00148 00027 ∂23-Jan-88 0931 CL-Windows-mailer CLX questions
C00151 00028 ∂23-Jan-88 1329 CL-Windows-mailer CLX questions
C00154 00029 ∂24-Jan-88 1337 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
C00156 00030 ∂24-Jan-88 1545 CL-Windows-mailer Ignored values
C00157 00031 ∂24-Jan-88 1615 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
C00161 00032 ∂25-Jan-88 1250 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
C00163 00033 ∂25-Jan-88 1649 CL-Windows-mailer Re: CLX :force-output-p and event-listen
C00166 00034 ∂25-Jan-88 1650 CL-Windows-mailer Re: Comments on CLUE
C00175 00035 ∂26-Jan-88 0048 CL-Windows-mailer Comments on CLUE
C00181 00036 ∂27-Jan-88 0921 CL-Windows-mailer CLX and Kyoto Common Lisp
C00183 00037 ∂27-Jan-88 1708 CL-Windows-mailer Re: Comments on CLUE
C00187 00038 ∂27-Jan-88 1832 CL-Windows-mailer Re: Comments on CLUE
C00193 00039 ∂27-Jan-88 2103 CL-Windows-mailer mailing address
C00194 00040 ∂27-Jan-88 2129 CL-Windows-mailer Re: mailing address
C00196 00041 ∂27-Jan-88 2141 CL-Windows-mailer Re: Comments on CLUE
C00200 00042 ∂27-Jan-88 2224 CL-Windows-mailer Re: mailing address
C00202 00043 ∂27-Jan-88 2258 CL-Windows-mailer Re: mailing address
C00204 00044 ∂28-Jan-88 1240 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
C00206 00045 ∂28-Jan-88 1956 CL-Windows-mailer Lisp Pointers
C00208 00046 ∂29-Jan-88 0914 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
C00211 00047 ∂29-Jan-88 1332 CL-Windows-mailer CLX resource extensions
C00214 00048 ∂01-Feb-88 1425 CL-Windows-mailer Please add me on the Distribution List
C00216 00049 ∂08-Feb-88 1715 CL-Windows-mailer CLX support for NOOP request?
C00218 00050 ∂09-Feb-88 0821 CL-Windows-mailer Re: CLX support for NOOP request?
C00221 00051 ∂12-Feb-88 1338 CL-Windows-mailer Re: CLX event queue
C00224 00052 ∂12-Feb-88 1403 CL-Windows-mailer CLX event queue
C00227 00053 ∂19-Feb-88 1211 CL-Windows-mailer CLX documentation
C00228 00054 ∂24-Feb-88 1651 CL-Windows-mailer How to handle timeout of 0 in Lucid's Lisp
C00234 00055 ∂16-Mar-88 1206 CL-Windows-mailer Re: CLX event queue
C00238 00056 ∂16-Mar-88 1222 CL-Windows-mailer Re: CLX event queue
C00242 00057 ∂16-Mar-88 1230 CL-Windows-mailer Please change my mail address
C00245 00058 ∂16-Mar-88 1346 CL-Windows-mailer Please change my mail address
C00248 00059 ∂16-Mar-88 1349 CL-Windows-mailer Re: CLX event queue
C00252 00060 ∂16-Mar-88 1459 CL-Windows-mailer Please change my mail address
C00255 00061 ∂16-Mar-88 1729 CL-Windows-mailer Please change my mail address
C00258 00062 ∂16-Mar-88 1459 CL-Windows-mailer Re: CLX event queue
C00262 00063 ∂16-Mar-88 1729 CL-Windows-mailer Re: CLX event queue
C00266 00064 ∂06-Apr-88 1627 CL-Windows-mailer CLX
C00271 00065 ∂14-Apr-88 1224 CL-Windows-mailer CLX Package Name
C00273 00066 ∂14-Apr-88 1529 CL-Windows-mailer CLX Package Name
C00277 00067 ∂25-Apr-88 1108 CL-Windows-mailer CLUE and with-gcontext
C00279 00068 ∂26-Apr-88 0930 CL-Windows-mailer CLUE code available
C00282 00069 ∂26-Apr-88 1029 CL-Windows-mailer CLUE code available
C00286 00070 ∂26-Apr-88 1050 CL-Windows-mailer CLUE and with-gcontext
C00288 00071 ∂26-Apr-88 1140 CL-Windows-mailer CLX spec
C00290 00072 ∂26-Apr-88 1631 CL-Windows-mailer Re: CLUE
C00298 00073 ∂27-Apr-88 0701 CL-Windows-mailer Re: CLUE code available
C00302 00074 ∂27-Apr-88 0913 CL-Windows-mailer RE: CLUE code available
C00303 00075 ∂27-Apr-88 1029 CL-Windows-mailer
C00305 00076 ∂27-Apr-88 1046 CL-Windows-mailer X
C00307 00077 ∂27-Apr-88 1515 CL-Windows-mailer Re: X windows capabilities question
C00309 00078 ∂27-Apr-88 1518 CL-Windows-mailer RE: CLUE code available
C00311 00079 ∂29-Apr-88 1913 CL-Windows-mailer Gnu indent hook for (CLX:event-case)
C00314 00080 ∂02-May-88 0730 CL-Windows-mailer Re: Gnu indent hook for (CLX:event-case)
C00316 00081 ∂10-May-88 1444 CL-Windows-mailer X Client Sofware for Symbolics
C00318 00082 ∂18-May-88 1401 CL-Windows-mailer Some questions
C00321 00083 ∂18-May-88 1434 CL-Windows-mailer Some questions
C00325 00084 ∂23-May-88 0335 CL-Windows-mailer enter-me
C00327 00085 ∂07-Jun-88 2033 CL-Windows-mailer looking for CLUE
C00329 00086 ∂10-Jun-88 0935 CL-Windows-mailer clue
C00331 00087 ∂10-Jun-88 1331 CL-Windows-mailer Re: clue
C00336 00088 ∂10-Jun-88 1515 CL-Windows-mailer Re: clue
C00339 00089 ∂12-Jun-88 1142 CL-Windows-mailer Re: clue
C00343 00090 ∂12-Jun-88 2101 CL-Windows-mailer please add me to the cl-windows mailing list
C00345 00091 ∂15-Jun-88 0254 CL-Windows-mailer CLX Interface Specification
C00347 00092 ∂15-Jun-88 0519 CL-Windows-mailer CLX Interface Specification
C00349 00093 ∂15-Jun-88 0816 CL-Windows-mailer Re: CLX Interface Specification
C00351 00094 ∂17-Jun-88 0031 CL-Windows-mailer please add me to the cl-windows mailing list
C00353 00095 ∂17-Jun-88 1652 CL-Windows-mailer Mailing list
C00355 00096 ∂18-Jun-88 1733 CL-Windows-mailer X11V2 on SUN with color monitors
C00357 00097 ∂27-Jun-88 0835 CL-Windows-mailer Re: clue
C00363 00098 ∂29-Jun-88 0350 CL-Windows-mailer X server on TI Explorer
C00365 00099 ∂30-Jun-88 1652 CL-Windows-mailer CLX Menus
C00367 00100 ∂01-Jul-88 0906 CL-Windows-mailer Re: CLX Menus
C00371 00101 ∂04-Jul-88 0805 CL-Windows-mailer Update on common windows?
C00375 00102 ∂07-Jul-88 1632 CL-Windows-mailer clue-review
C00377 00103 ∂18-Jul-88 0248 CL-Windows-mailer window systems
C00379 00104 ∂22-Jul-88 1407 CL-Windows-mailer clue-review bounce list
C00381 00105 ∂24-Jul-88 2110 CL-Windows-mailer CLUE
C00383 00106 ∂15-Aug-88 0345 CL-Windows-mailer please remove my address from the cl-windows mailing list
C00385 00107 ∂31-Aug-88 1206 CL-Windows-mailer CLUE 1.15 availaible
C00387 00108 ∂01-Sep-88 0705 CL-Windows-mailer Re: CLUE 1.15 availaible
C00389 00109 ∂06-Sep-88 1510 CL-Windows-mailer lispx e-mail distribution list
C00395 00110 ∂07-Sep-88 0735 CL-Windows-mailer Re: lispx e-mail distribution list
C00406 00111 ∂20-Sep-88 2342 CL-Windows-mailer X Consortium priorities
C00409 00112 ∂21-Sep-88 0650 CL-Windows-mailer Re: X Consortium priorities
C00411 00113 ∂21-Sep-88 0748 CL-Windows-mailer X Consortium priorities
C00413 00114 ∂21-Sep-88 0934 CL-Windows-mailer Re: X Consortium priorities
C00415 00115 ∂22-Sep-88 1149 CL-Windows-mailer Re: International character sets
C00417 00116 ∂22-Sep-88 1430 CL-Windows-mailer Using clx with kcl
C00420 00117 ∂26-Sep-88 0923 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00423 00118 ∂26-Sep-88 1019 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00427 00119 ∂27-Sep-88 0110 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00429 00120 ∂27-Sep-88 0417 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00431 00121 ∂27-Sep-88 0850 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00433 00122 ∂05-Oct-88 2003 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00439 00123 ∂06-Oct-88 0020 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00456 00124 ∂06-Oct-88 0517 CL-Windows-mailer at least one's blooming
C00459 00125 ∂06-Oct-88 0809 CL-Windows-mailer CLUE and CLX
C00466 00126 ∂06-Oct-88 0821 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00470 00127 ∂06-Oct-88 1113 CL-Windows-mailer More wood for the flames...
C00473 00128 ∂06-Oct-88 1121 CL-Windows-mailer Re: CLX and OOP
C00477 00129 ∂06-Oct-88 1207 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00482 00130 ∂06-Oct-88 1223 CL-Windows-mailer Re: CLX and OOP
C00485 00131 ∂06-Oct-88 1705 CL-Windows-mailer Re: CLUE and 1K Primrose Path
C00490 00132 ∂06-Oct-88 1901 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00493 00133 ∂06-Oct-88 1907 CL-Windows-mailer Re: "window virtual machine"
C00497 00134 ∂06-Oct-88 1909 CL-Windows-mailer Re: LISP X based toolkits
C00505 00135 ∂07-Oct-88 0743 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00507 00136 ∂07-Oct-88 0824 CL-Windows-mailer Re: CLUE and CLX
C00510 00137 ∂07-Oct-88 0833 CL-Windows-mailer Re: CLX resource-ids
C00512 00138 ∂07-Oct-88 1448 CL-Windows-mailer Needed: Info on LISP X based toolkits
C00524 00139 ∂08-Oct-88 1320 CL-Windows-mailer Re: portable CLOS window system
C00529 00140 ∂08-Oct-88 1327 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00535 00141 ∂08-Oct-88 1342 CL-Windows-mailer Re: "window virtual machine"
C00538 00142 ∂08-Oct-88 1344 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
C00543 00143 ∂08-Oct-88 1428 CL-Windows-mailer "...Both C and LISP are ANSI standard languages."
C00546 00144 ∂11-Oct-88 0302 CL-Windows-mailer LISP X based toolkits
C00550 00145 ∂11-Oct-88 0302 CL-Windows-mailer LISP X based toolkits
C00554 00146 ∂11-Oct-88 0632 CL-Windows-mailer LISP X based toolkits
C00556 00147 ∂11-Oct-88 0726 CL-Windows-mailer CLX, CLUE and LISP/X Toolkits...
C00563 00148 ∂11-Oct-88 0922 CL-Windows-mailer Re: run-time method definition
C00569 00149 ∂11-Oct-88 1019 CL-Windows-mailer portable CLOS window system
C00579 00150 ∂11-Oct-88 1330 CL-Windows-mailer Re: run-time method definition
C00585 00151 ∂12-Oct-88 0322 CL-Windows-mailer run-time method definition
C00590 00152 ∂27-Oct-88 1906 CL-Windows-mailer OBJECT-ORIENTED CLX
C00632 00153 ∂28-Oct-88 0921 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00644 00154 ∂31-Oct-88 1609 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00651 00155 ∂01-Nov-88 1020 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00657 00156 ∂01-Nov-88 1102 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00661 00157 ∂01-Nov-88 1539 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00667 00158 ∂01-Nov-88 1932 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00673 00159 ∂01-Nov-88 2204 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00676 00160 ∂02-Nov-88 0445 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00698 00161 ∂02-Nov-88 0837 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00709 00162 ∂03-Nov-88 1034 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00713 00163 ∂03-Nov-88 1123 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00718 00164 ∂05-Nov-88 2027 CL-Windows-mailer clx on an Apollo
C00721 00165 ∂09-Nov-88 1120 CL-Windows-mailer Status.of.CLOS.and.associated.software.for"production"work
C00726 00166 ∂09-Nov-88 2218 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
C00729 00167 ∂11-Nov-88 1156 CL-Windows-mailer PCL, CLX, and CLUE in KCL
C00732 00168 ∂17-Nov-88 0706 CL-Windows-mailer mailing list
C00733 00169 ∂18-Nov-88 0702 CL-Windows-mailer common lisp stream to an X window
C00736 00170 ∂30-Nov-88 1215 CL-Windows-mailer common lisp stream to an X window
C00742 00171 ∂02-Dec-88 0704 CL-Windows-mailer Other-LISP-versions-of-CLUE
C00745 00172 ∂02-Dec-88 0709 CL-Windows-mailer streams to common lisp windows.
C00749 00173 ∂02-Dec-88 1150 CL-Windows-mailer Other-LISP-versions-of-CLUE
C00751 00174 ∂05-Dec-88 1149 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
C00754 00175 ∂13-Dec-88 2122 CL-Windows-mailer Re: lookup-color deadlock
C00758 00176 ∂16-Dec-88 1304 CL-Windows-mailer CLX create-colormap question
C00760 00177 ∂17-Dec-88 0928 CL-Windows-mailer Re: CLX create-colormap question
C00762 00178 ∂19-Dec-88 1816 CL-Windows-mailer Using .snf fonts
C00764 00179 ∂27-Dec-88 0825 CL-Windows-mailer Other-LISP-versions-of-CLUE
C00767 00180 ∂06-Jan-89 0935 CL-Windows-mailer Other-LISP-versions-of-CLUE
C00771 00181 ∂06-Jan-89 1121 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
C00776 00182 ∂06-Jan-89 2209 CL-Windows-mailer Please add my name to your List
C00779 00183 ∂06-Jan-89 2247 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
C00781 00184 ∂09-Jan-89 1203 CL-Windows-mailer Other-LISP-versions-of-CLUE
C00783 00185 ∂30-Jan-89 1233 CL-Windows-mailer Where to get CLUE
C00785 00186 ∂30-Jan-89 1434 CL-Windows-mailer Lisp Xperts' BOF
C00792 00187 ∂31-Jan-89 1202 CL-Windows-mailer Help!!!!
C00795 00188 ∂31-Jan-89 1226 CL-Windows-mailer Help!!!!
C00798 00189 ∂07-Feb-89 0819 CL-Windows-mailer I/O generic functions
C00812 00190 ∂07-Feb-89 1016 Common-Lisp-Object-System-mailer Re: I/O generic functions
C00814 00191 ∂07-Feb-89 1033 Common-Lisp-Object-System-mailer Re: I/O generic functions
C00818 00192 ∂07-Feb-89 1821 CL-Windows-mailer CLX and ICCCM
C00838 00193 ∂07-Feb-89 2005 CL-Windows-mailer CLX and ICCCM
C00858 00194 ∂07-Feb-89 2005 CL-Cleanup-mailer I/O generic functions
C00862 00195 ∂09-Feb-89 1135 CL-Windows-mailer Patches for CLX under Lucid 3.0 and X11R2
C00888 00196 ∂13-Feb-89 2052 CL-Windows-mailer topics
C00891 00197 ∂14-Feb-89 1636 CL-Windows-mailer Re: CLX and ICCCM
C00896 00198 ∂15-Feb-89 0443 CL-Windows-mailer Re: CLX and ICCCM
C00898 00199 ∂16-Feb-89 1917 CL-Windows-mailer Re: CLX and ICCCM
C00900 00200 ∂17-Feb-89 0716 CL-Windows-mailer CL-PEX?
C00903 00201 ∂17-Feb-89 0743 CL-Windows-mailer Re: CL-PEX?
C00905 00202 ∂17-Feb-89 0849 CL-Windows-mailer Re: CL-PEX?
C00907 00203 ∂17-Feb-89 1414 CL-Windows-mailer Recent Lucid patches for CLX
C00913 00204 ∂20-Feb-89 0618 CL-Windows-mailer Re: CL-PEX?
C00916 00205 ∂20-Feb-89 0634 CL-Windows-mailer Re: CL-PEX?
C00919 00206 ∂20-Feb-89 0642 CL-Windows-mailer Recent Lucid patches for CLX
C00925 00207 ∂22-Feb-89 1010 CL-Windows-mailer Profuse apologies
C00927 00208 ∂28-Feb-89 1504 CL-Windows-mailer Newer version of preliminary clx document available
C00930 00209 ∂01-Mar-89 1134 CL-Windows-mailer Please change address to "tbardasz@cvbnet.prime.com"
C00934 00210 ∂08-Mar-89 1508 CL-Windows-mailer CLX and ICCCM
C00941 00211 ∂08-Mar-89 1511 CL-Windows-mailer apologies for the inadvertent cc to cl-windows
C00943 00212 ∂09-Mar-89 1636 CL-Windows-mailer CLX doc update
C00948 00213 ∂09-Mar-89 1832 CL-Windows-mailer Re: CLX and ICCCM
C00950 00214 ∂10-Mar-89 0832 CL-Windows-mailer Multithreaded Common Lisps
C00956 00215 ∂13-Mar-89 0423 CL-Windows-mailer need to get CLX & CLUE working on a sun4 running lucid lisp
C00961 ENDMK
C⊗;
∂02-Jan-88 1049 CL-Windows-mailer gcontext-function
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 10:49:32 PST
Date: 2 Jan 1988 13:46-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: cl-windows@SAIL.STANFORD.EDU
Subject: gcontext-function
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <568147579/rfb@SPICE.CS.CMU.EDU>
In Sun/Lucid Lisp, it appears that all possible values have the same
effect; that of XOR. Could someone send me an example of code that
preforms some graphics operation using a different gcontext-function so
that I can determine whether the brain damage is local?
∂04-Jan-88 0146 CL-Windows-mailer more clx questions
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 01:46:37 PST
Received: from suntoo.sun.com ([192.9.0.45]) by Sun.COM (4.0/SMI-3.2)
id AA25889; Sat, 2 Jan 88 23:45:40 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA05504; Sat, 2 Jan 88 23:46:16 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA03389; Sat, 2 Jan 88 22:53:39 EST
Received: from psilocybin.sun.com by eti.com (3.2/SMI-3.2)
id AA29509; Sat, 2 Jan 88 22:35:34 EST
Received: by psilocybin.sun.com (3.2/SMI-3.2)
id AA00705; Sat, 2 Jan 88 22:35:47 EST
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801030335.AA00705@psilocybin.sun.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: more clx questions
Why is it that the specification FONT argument for TEXT-WIDTH,
TEXT-EXTENTS, DRAW-GLYPHS, etc. in the keyword arguments comes first
in the distributed implementation when the specification (doc.lisp)
puts it in the keyword arguments. It strikes me that this is an
improvement, but the spec should be updated.
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them? This seems *very*
wrong.
Is there any way to find out how wide a string is without doing any
CONSing?
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Why is EVENT-LISTEN specified to take a timeout argument? Shouldn't
it return the number of events available ``right now?''
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂04-Jan-88 1144 CL-Windows-mailer Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 11:44:33 PST
Date: 4 Jan 1988 14:44-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: cl-windows@sail.stanford.edu
Subject: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <568323856/rfb@SPICE.CS.CMU.EDU>
Last month, I read through ``Common Lisp User Interface Environment'' and I
have some general comments about the proposal as well as some specific nits
to pick about various things in the document.
First my general comments.
I don't have any immediate plans to use the CLUE software. Instead, I
have modified CLX slightly such that DRAWABLEs, WINDOWs and PIXMAPs are
CLOS classes rather than structures and CREATE-WINDOW accepts a :WINDOW
keyword argument. When the :WINDOW argument is specified,
CREATE-WINDOW destructively modified it rather than consing a new
WINDOW instance. For sub-classes of WINDOW, the instance
initialization process includes calling CREATE-WINDOW on the instance
using itself as the :WINDOW object. The CLX modifications took me less
than an hour to implement and comprise about a page of code.
I've found that this object oriented CLX lets me do the sorts of object
oriented things that I wanted to do without having to adopt all aspects of
CLUE. My opinion is that it would be much better to have a lot of different
people building CLUE-like things using such an interface before making any
serious attempt at standardization, but I wouldn't be terribly shocked to
have others convince me that I'm wrong about this. The X protocol is
relatively stable and I think that CLX is a major win in that it provides a
nice lisp-based interaction paradigm that maps fairly directly onto the
protocol definition. Mostly I think that CLUE is an attempt to standardize
too much too soon.
I also got the impression that a lot of the the (generic) functions proposed
in CLUE are just arbitrary name changes which don't use ``conc-names'' so
that they will have a high probability of causing all sorts of package
conflicts which shouldn't be necessary. PRESENT vs. MAP-WINDOW is one
example of what I'm talking about.
Below are my more specific comments, organized according to the CLUE spec
organization.
Chapter 1
1.3.1 Contacts, Composites and Interactive Streams
Why is it that the default CONTACT class, which has over 70 slots, doesn't
include a slot for children when it is a sub-class of WINDOW which has
children? In specifying my own class hierarchy, I didn't see any need to
make a distinct classes for composite and non-composite objects although I
considered it at first.
Chapter 2
2.1 The Contact Class
Why is the form DEFCONTACT used rather than DEFCLASS? It appears that there
are some typos involving indentation and parenthesization of the massive
DEFCONTACT form.
2.1.1 Contact Creation
In the second paragraph, a reference is made to ``The generic MAKE-INSTANCE
function''. CLOS provides a function named MAKE-INSTANCE, but not a generic
function.
2.2 Defining a Contact Class
DEFCONTACT should not be using ``the property list of the class name symbol
to store information about the resources needed by instances of the class.''
CLOS classes are first-class, specializable objects so there's no need for
such plist hacks.
Chapter 3
In general, I would have guessed that having specializable generic functions
with names like BUTTON-PRESS, etc. and which accepted keyword arguments like
those passed to the CLX event handling function would have been a better
approach than the mechanism proposed in CLUE. To specialize event handling,
one might define a sub-class of WINDOW named BUTTON which specialized
ENTER-WINDOW, BUTTON-PRESS, etc. to invoke other g.f.'s with names like
ACTIVATE-BUTTON, SELECT-BUTTON, FIRE-BUTTON, etc.
3.8.1 Event Specifications
Why is there :UP, but not :DOWN?
3.8.2 Event translation
As I mentioned above, I think that a very different approach is prefereable,
however even if the CLUE approach to event handling is adopted, I don't see
the desireability of specifying an association list. Mostly this is because
of my desire to avoid using lists whenever there's a clean efficient
alternative.
Chapter 6
I think that what this chapter points out the need for the Common Lisp
standard to specify a bit more about what streams are and how one goes about
creating new kinds of streams. Having this all be implementation dependant
is a real pain (especially when using implementations like Lucid which
insist on hiding as much of their internals as possible!)
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂04-Jan-88 1516 CL-Windows-mailer CLX server extension facilities
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:16:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj01627; 4 Jan 88 17:31 EST
Received: from csc.ti.com by RELAY.CS.NET id az08411; 4 Jan 88 17:15 EST
Received: from SI by tilde id AA01971; Mon, 4 Jan 88 15:51:50 CST
Message-Id: <2777320288-1554914@SI>
Sender: OREN%si.csc.ti.com@RELAY.CS.NET
Date: Mon, 4 Jan 88 15:51:28 CST
From: LaMott Oren <Oren%home.csc.ti.com@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX server extension facilities
One of the things CLX should have had from the beginning is a
mechanism for handling protocol extensions. How does the following
look?
(defmacro define-extension (name &key events errors)
;; Define extension NAME with EVENTS and ERRORS.
;; Note: The case of NAME is important.
;; To define the request, Use:
;; (with-buffer-request (display (extension-opcode ,name)) ,@body)
;; See the REQUESTS file for lots of examples.
;; To define event handlers, use declare-event.
;; To define error handlers, use declare-error and define-condition.
(declare (type stringable name)
(type (list symbol) events errors)))
(defmacro extension-opcode (display name)
;; Returns the major opcode for extension NAME.
;; This is a macro to enable NAME to be interned for fast run-time
;; retrieval.
;; Note: The case of NAME is important.
(declare (type display display)
(type stringable name)
(values card8)))
(defmacro define-error (error-key function)
;; Associate a function with ERROR-KEY which will be called with
;; parameters DISPLAY and REPLY-BUFFER and returns a plist of
;; keyword/value pairs which will be passed on to the error handler.
;; A compiler warning is printed when ERROR-KEY is not defined in a
;; preceding DEFINE-EXTENSION.
;; Note: REPLY-BUFFER may used with the READING-EVENT and READ-type
;; macros for getting error fields. See DECODE-CORE-ERROR for
; an example.
(declare (type symbol error-key)
(type function function)))
;; All core errors use this, so we make it available to extensions.
(defun decode-core-error (display event &optional arg)
;; All core errors have the following keyword/argument pairs:
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; In addition, many have an additional argument that comes from the
;; same place in the event, but is named differently. When the ARG
;; argument is specified, the keyword ARG with card32 value starting
;; at byte 4 of the event is returned with the other keyword/argument
;; pairs.
(declare (type display display)
(type reply-buffer event)
(type (or null keyword) arg)
(values keyword/arg-plist)))
;; This isn't new, just extended.
(defmacro declare-event (event-codes &body declares)
;; Used to indicate the keyword arguments for handler functions in
;; process-event and event-case.
;; Generates functions used in SEND-EVENT.
;; A compiler warning is printed when all of EVENT-CODES are not
;; defined by a preceding DEFINE-EXTENSION.
;; See the INPUT file for lots of examples.
(declare (type (or keyword (list keywords)) event-codes)
(type (alist (field-type symbol) (field-names (list symbol)))
declares)))
(DEFMACRO define-gcontext-accessor (name set-function &optional default-value)
;; This will define a new gcontext accessor called NAME.
;; Defines the gcontext-NAME accessor function and its defsetf.
;; Gcontext's will cache DEFAULT-VALUE and the last value SETF'ed when
;; gcontext-cache-p is true. The NAME keyword will be allowed in
;; CREATE-GCONTEXT, WITH-GCONTEXT, and COPY-GCONTEXT-COMPONENTS.
;; SET-FUNCTION will be called with parameters (GCONTEXT NEW-VALUE)
;; from create-gcontext, force-gcontext-changes, copy-gcontext and
;; copy-gcontext-components.
(DECLARE (type symbol name)
(type function set-function)))
;; To aid extension implementors in attaching additional information to
;; clx data structures, the following accessors (with SETF's) will be
;; defined. GETF can be used on these to extend the structures.
display-plist ;; already exists, but isn't documented
screen-plist
visual-info-plist
gcontext-plist
font-plist
In addition, as an aid for linking CLX windows with toolkit data
structures (without the aid of an additional hash table) I think it
would be good to add drawable-plist.
∂05-Jan-88 1006 CL-Windows-mailer Re: CLX server extension facilities
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 88 10:06:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad12333; 5 Jan 88 12:53 EST
Received: from csc.ti.com by RELAY.CS.NET id aj14314; 5 Jan 88 12:46 EST
Received: from SI by tilde id AA22048; Tue, 5 Jan 88 11:43:31 CST
Message-Id: <2777391745-5850836@SI>
Sender: OREN%si.csc.ti.com@RELAY.CS.NET
Date: Tue, 5 Jan 88 11:42:25 CST
From: LaMott Oren <Oren%home.csc.ti.com@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX server extension facilities
In-Reply-To: Msg of Mon, 4 Jan 88 15:51:28 CST from LaMott Oren <Oren@home.csc.ti.com>
I've discovered that define-gcontext-accessor needs a copy-function
parameter. I had previously assumed that the set-function could always
be used for copying. Here's the corrected version:
(DEFMACRO define-gcontext-accessor (name &key default set-function copy-function)
;; This will define a new gcontext accessor called NAME.
;; Defines the gcontext-NAME accessor function and its defsetf.
;; Gcontext's will cache DEFAULT-VALUE and the last value SETF'ed when
;; gcontext-cache-p is true. The NAME keyword will be allowed in
;; CREATE-GCONTEXT, WITH-GCONTEXT, and COPY-GCONTEXT-COMPONENTS.
;; SET-FUNCTION will be called with parameters (GCONTEXT NEW-VALUE)
;; from create-gcontext, and force-gcontext-changes.
;; COPY-FUNCTION will be called with parameters (src-gc dst-gc src-value)
;; from copy-gcontext and copy-gcontext-components.
;; The copy-function defaults to:
;; (lambda (ignore dst-gc value)
;; (if value
;; (,set-function dst-gc value)
;; (error "Can't copy unknown GContext component ~a" ',name)))
(DECLARE (type symbol name)
(type t default)
(type (function (gcontext t) t) set-function) ;; required
(type (or null (function (gcontext gcontext t) t))
copy-function)))
∂05-Jan-88 1551 CL-Windows-mailer more clx questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 15:51:40 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 111213; Tue 5-Jan-88 18:51:28 EST
Date: Tue, 5 Jan 88 18:51 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: more clx questions
To: sunpitt!eti!rick@Sun.COM, cl-windows@sail.stanford.edu
In-Reply-To: <8801030335.AA00705@psilocybin.sun.com>
Message-ID: <880105185137.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why is it that the specification FONT argument for TEXT-WIDTH,
TEXT-EXTENTS, DRAW-GLYPHS, etc. in the keyword arguments comes first
in the distributed implementation when the specification (doc.lisp)
puts it in the keyword arguments. It strikes me that this is an
improvement, but the spec should be updated.
Changing the documentation seems fine with me.
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Is there any way to find out how wide a string is without doing any
CONSing?
Yes, and the current implementation doesn't (at least it didn't when I
tried it on a 36xx).
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Both accept anything. What I guess you are really asking is why the
existing implementation of TRANSLATE-DEFAULT only does character to
index conversion for strings, as opposed to any sequence containing
characters. One answer is that I don't recall there being any real
resolution of how the default translation should work, or where it
should come from, but perhaps someone can set me straight.
Why is EVENT-LISTEN specified to take a timeout argument? Shouldn't
it return the number of events available ``right now?''
It does if you pass a timeout of zero, which is the default. The
timeout simply provides some additional capability.
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Because no one has provided an implementation of BUFFER-READ-DEFAULT
for Lucid that handles timeouts.
∂06-Jan-88 1524 CL-Windows-mailer Re: CLX question
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 15:24:37 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 111615; Wed 6-Jan-88 18:28:34 EST
Date: Wed, 6 Jan 88 18:28 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX question
To: Kimbrough%dsg.csc.ti.com@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <2776980073-2810538@Sierra>
Message-ID: <880106182829.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 31 Dec 87 17:21:13 CST
From: Kerry Kimbrough <Kimbrough%dsg.csc.ti.com@RELAY.CS.NET>
(event-window (GETF event-keys
(CASE event-key
((:configure-request ...) :parent)
((:circulate-notify ...) :event-window)
(otherwise :window)))))
Servicable, but it would be cleaner and more reliable if it was always the same
keyword (say, :event-window). Same goes for event dispatching, too.
(I note that the C Xlib doesn't use uniform names, but uses a
by-position-in-structure kludge when matching windows.)
I would prefer not to make an incompatible change. Better, it seems to
me, is to simply allow use of :event-window on all window-based events,
Thus, for example, :event-window could be used as a synonym for :parent
in :configure-request events.
The only "difficulty" is whether :event-window should be permitted in
queue-event and send-event. It could either be disallowed, or require
that if both synonyms are given they must be equal, or say it "is an
error" if synonyms with differing values are given. Off-hand, I would
lean to "is an error".
∂06-Jan-88 2216 CL-Windows-mailer object oriented CLX patches
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 22:16:36 PST
Received: from suntoo.sun.com (suntoo-bb.sun.com) by Sun.COM (4.0/SMI-3.2)
id AA01768; Wed, 6 Jan 88 22:17:09 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA28089; Wed, 6 Jan 88 22:19:17 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA06461; Wed, 6 Jan 88 23:51:53 EST
Received: by eti.com (3.2/SMI-3.2)
id AA13999; Mon, 4 Jan 88 18:23:49 EST
Date: Mon, 4 Jan 88 18:23:49 EST
From: sunpitt!eti!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801042323.AA13999@eti.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: object oriented CLX patches
Cc: sunpitt!mhb@Sun.COM
Here are the patches that I mentioned in a previous message.
*** original-CLX/clx.lisp Wed Nov 18 06:14:10 1987
--- CLX/clx.lisp Thu Dec 17 23:21:45 1987
***************
*** 69,75 ****
;; Note: all of the following is in the package XLIB.
! (in-package "XLIB" :use '("LISP"))
(defparameter *protocol-major-version* 11.)
(defparameter *protocol-minor-version* 0)
--- 69,75 ----
;; Note: all of the following is in the package XLIB.
! (in-package "XLIB" :use '("LISP" "CLOS"))
(defparameter *protocol-major-version* 11.)
(defparameter *protocol-minor-version* 0)
***************
*** 247,266 ****
(last-width nil :type (or null card29)) ; Accumulated width of last string
(plist) ; hook for extension to hang data
)
;;(deftype drawable () '(or window pixmap))
! (defstruct drawable
! (id 0 :type resource-id)
! (display nil :type (or null display))
! )
! (defstruct (window (:include drawable))
! )
! (defstruct (pixmap (:include drawable))
! )
!
(defstruct colormap
(id 0 :type resource-id)
(display nil :type (or null display))
--- 247,324 ----
(last-width nil :type (or null card29)) ; Accumulated width of last string
(plist) ; hook for extension to hang data
)
+ !
+ ;;; This page has been converted by Rick Busdiecker to make DRAWABLE,
+ ;;; WINDOW and PIXMAP all be Classes rather than Structures.
+ ;;;
;;(deftype drawable () '(or window pixmap))
! ;;; (defstruct drawable
! ;;; (id 0 :type resource-id)
! ;;; (display nil :type (or null display))
! ;;; )
! ;;;
! (defclass drawable ()
! ((id :initform 0)
! (display :initform nil)))
! (defun make-drawable (&rest arguments)
! (apply #'clos:make-instance 'drawable arguments))
! (defun drawable-id (drawable)
! (slot-value drawable 'id))
! (defsetf drawable-id (drawable) (new-drawable-id)
! `(setf (slot-value ,drawable 'id) ,new-drawable-id))
! (defun drawable-display (drawable)
! (slot-value drawable 'display))
! (defsetf drawable-display (drawable) (new-drawable-display)
! `(setf (slot-value ,drawable 'display) ,new-drawable-display))
! (defun drawable-p (object)
! (typep object 'drawable))
! (defun copy-drawable (drawable)
! (make-instance 'drawable
! :id (slot-value drawable 'id)
! :display (slot-value drawable 'display)))
! ;;; (defstruct (window (:include drawable)))
! ;;;
! (defclass window (drawable) ())
! (defun make-window (&rest arguments)
! (apply #'clos:make-instance 'window arguments))
! (defun window-id (window)
! (slot-value window 'id))
! (defsetf window-id (window) (new-window-id)
! `(setf (slot-value ,window 'id) ,new-window-id))
! (defun window-display (window)
! (slot-value window 'display))
! (defsetf window-display (window) (new-window-display)
! `(setf (slot-value ,window 'display) ,new-window-display))
! (defun window-p (object)
! (typep object 'window))
! (defun copy-window (window)
! (make-instance 'window
! :id (slot-value window 'id)
! :display (slot-value window 'display)))
! ;;; (defstruct (pixmap (:include drawable)))
! ;;;
! (defclass pixmap (drawable) ())
! (defun make-pixmap (&rest arguments)
! (apply #'clos:make-instance 'pixmap arguments))
! (defun pixmap-id (pixmap)
! (slot-value pixmap 'id))
! (defsetf pixmap-id (pixmap) (new-pixmap-id)
! `(setf (slot-value ,pixmap 'id) ,new-pixmap-id))
! (defun pixmap-display (pixmap)
! (slot-value pixmap 'display))
! (defsetf pixmap-display (pixmap) (new-pixmap-display)
! `(setf (slot-value ,pixmap 'display) ,new-pixmap-display))
! (defun pixmap-p (object)
! (typep object 'pixmap))
! (defun copy-pixmap (pixmap)
! (make-instance 'pixmap
! :id (slot-value pixmap 'id)
! :display (slot-value pixmap 'display)))
! !
(defstruct colormap
(id 0 :type resource-id)
(display nil :type (or null display))
*** original-CLX/requests.lisp Wed Nov 18 06:14:13 1987
--- CLX/requests.lisp Fri Dec 18 01:24:43 1987
***************
*** 30,36 ****
bit-gravity gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
! colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in
;; the request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
--- 30,45 ----
bit-gravity gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
! colormap cursor
!
! ;;
! ;; This is a hack added by Rick Busdiecker to
! ;; specify the CLOS Class of the object that
! ;; CREATE-WINDOW returns. See more below.
! ;;
! (window nil)
!
! )
;; Display is obtained from parent. Only non-nil attributes are passed on in
;; the request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
***************
*** 53,62 ****
(type (or null (member :none) cursor) cursor))
(declare-values window)
(let* ((display (window-display parent))
! (window (make-window :display display))
! (wid (allocate-resource-id display window 'window))
back-pixmap back-pixel
border-pixmap border-pixel)
(setf (window-id window) wid)
(case background
((nil) nil)
--- 62,92 ----
(type (or null (member :none) cursor) cursor))
(declare-values window)
(let* ((display (window-display parent))
!
! ;;
! ;; This is more of Rick Busdiecker's change. Immediately
! ;; inside this LET* WINDOW is set to the value that it would
! ;; have gotten in the LET* unless CREATE-WINDOW got a non-NIL
! ;; :WINDOW argument.
! ;;
! ;; (window (make-window :display display))
! ;; (wid (allocate-resource-id display window 'window))
! ;;
!
! wid
back-pixmap back-pixel
border-pixmap border-pixel)
+
+ ;;
+ ;; This is the last part of the changes by Rick Busdiecker. It
+ ;; makes WINDOW be an object of class WINDOW unless it is already
+ ;; non-NIL.
+ ;;
+ (if window
+ (setf (window-display window) display)
+ (setf window (make-window :display display)))
+ (setf wid (allocate-resource-id display window 'window))
+
(setf (window-id window) wid)
(case background
((nil) nil)
∂07-Jan-88 1316 CL-Windows-mailer proposed C Xlib changes that CLX should mimic
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 13:16:47 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 7 Jan 88 16:14-EST
Date: Thu, 7 Jan 88 16:18 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: proposed C Xlib changes that CLX should mimic
To: cl-windows@sail.stanford.edu
Message-ID: <880107161840.0.RWS@KILLINGTON.LCS.MIT.EDU>
[I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
should similarly be changed to force output only when blocking to wait
for an event. Note that XLIB:EVENT-LISTEN already does not force
output, which is consistent with the desired new semantics for XPending.
- RWS]
Date: Thu, 7 Jan 88 11:38:17 pst
From: jg@src.dec.com (Jim Gettys)
To: xtensions@ATHENA.MIT.EDU
Subject: Proposed changes to Xlib event routines. IMPORTANT, PLEASE READ!
Recent performance work on the toolkit and server has uncovered an
unfortunate design problem in Xlib. First some history:
The basic internal design of Xlib represents the third attempt, but
for all of that, is 2 1/2 years old. In general, it has served well, but it
predates any serious toolkits, and much understanding of what this would
imply. Joel McCormack and Mike Chow have been working to speed up the
toolkit, and have largely succeeded, with a 2 1/2 time improvement in
creation and startup on some sample programs (one creates 270 widgets!).
One of the problems found and a fix prototyped for is in the
definition of the event handing routines. Currently, they are defined to
ALWAYS flush the output buffer. A concrete example is in order here; let
us use xmh.
1) xmh creates all its windows. In V11, all of this is being
cleverly buffered up in the output buffer (a great improvement
over V10, where no buffering was possible). Xmh maps its top level window
and then goes blocked in XNextEvent, which flushes the buffer.
2) Now the server gets all the window creation requests, and cogitates
for a while. 80 or so subwindows are exposed, and all expose events
are sent to xmh.
3) in xmh, XNextEvent unblocks, and cleverly reads as many events
as it can and enqueues them on the input queue. So far so good.
4) XNextEvent returns the first expose event to the toolkit
5) the toolkit dispatches it, and we find a button has been exposed,
and calls the button widget.
6) The button widget calls a text routine to output 5 or 6
characters of the button label, these are stored in the output buffer,
and it is then finised with its work.
7) the toolkit calls XNextEvent to get the next event.
XNextEvent causes the output buffer to be flushed and a write occurs to
the connection, and we go to step 4. Here is where the problem lies.
So for each of 80 or so exposure events, we end up performing a write call,
rather than having the requests appropriately buffered up and sent in
a single request. At many milliseconds/write, this adds up lots of time,
though before the other performance work was done, it was in the noise,
it is now significant (not to mention the flurry of 80 or so packets
each time xmh was mapped or otherwise exposed). This may account for
of order a second of cpu time in xmh on many workstations, and can
be cut dramatically.
Why does XNextEvent and similar event routines flush at all, you may ask?
It is basically to ensure that programs run correctly without programmers
having to think about the output buffer constantly. If XNextEvent does not
ensure the output buffer is empty before blocking, your program
could easily deadlock; the event you are waiting for may be generated
by a request that was never transmitted if it does not flush the buffer.
Proposed Solution:
------------------
Modify blocking event routines to only flush the output buffer when they
would block, rather than the current semantics of always flushing the
output buffer. Modify non-blocking event (for example XCheckIfEvent)
routines to flush only when they return with no event. For non-blocking
routines, some flush should occur to ensure against deadlock. These
changes are of order a couple lines of code per affected routine. Modify
the Xlib spec to conform. The proposed wording is below. From
experiment, existing programs we have relinked against a modified Xlib
work unchanged with the exception of programs and libraries using
XPending. They may require a flush added before the call to XPending. Old
binaries of course have no risk of problems, as this is strictly a library
change. One should be guaranteed of eventually sending the data if the
routine is called in a loop.
Alternatives:
-------------
1) Doing nothing at all means we live with a very serious performance
bottleneck forever, particularly for toolkits based on Xlib.
2) Provide yet another set of blocking event routines which only flush
when they would block. Retire the old routines, but leave them in the
library.
o advantage: zero risk of breaking code,
o disadvantages: existing code never speeds up, even when
relinked. Two sets of (almost) identical routines exist, causing
confusion.
Opinion:
--------
I believe that it is very unlikely that existing code will break given the
proposed changes to the event routines except for XPending, given our
experience with the code we have in hand. Having two versions of routines
I believe is a very bad idea, even presuming we could figure out other
reasonable names for new versions. Leaving things as they are represents
at least a 25% performance hit for many toolkit applications (at current
performance, more as things get better optimized), not to mention the load
on the network currently being generated.
We desire opinions in particular on whether XPending's definition should
change, as we have had one case in the toolkit where an XFlush had to be
added for it to work with these modifications. Other code tested has not
been affected. XPending is typically only used by quite sophisticated
applications; we believe the impact to be small. If there is sufficient
push back on XPending, there are alternatives such as introducing a new
call, or only flushing when the queue is empty. Our belief at the moment
is that people using XPending should know what they are doing, and it is
not a great idea to have another routine if not really needed, but it is
an alternative if opinion against a change known to cause problems to
existing code is strong.
Proposed changes to the Xlib spec:
----------------------------------
[omitted - RWS]
-----------------
P.S. This problem has been important enough that I have broken my
resolution not to work on X problems for the rest of the time I am a
visitor at SRC (what I do after SRC I have not yet decided). Bob and I
both endorse this change strongly. Your opinions are solicited.
Jim Gettys
Systems Research Center
Digitial Equipment Corporation
∂07-Jan-88 1410 CL-Windows-mailer Re: more clx questions
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 7 Jan 88 14:09:55 PST
Received: from suntoo.sun.com ([192.9.0.45]) by Sun.COM (4.0/SMI-3.2)
id AA12672; Thu, 7 Jan 88 12:44:33 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA05430; Thu, 7 Jan 88 12:45:10 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA08524; Thu, 7 Jan 88 14:28:30 EST
Received: from psilocybin.sun.com by eti.com (3.2/SMI-3.2)
id AA07712; Thu, 7 Jan 88 14:28:31 EST
Received: by psilocybin.sun.com (3.2/SMI-3.2)
id AA03252; Thu, 7 Jan 88 14:29:05 EST
Date: Thu, 7 Jan 88 14:29:05 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801071929.AA03252@psilocybin.sun.com>
To: sunpitt!sun!ZERMATT.LCS.MIT.EDU!RWS@Sun.COM
Subject: Re: more clx questions
Cc: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Date: Tue, 5 Jan 88 18:51 EST
From: Robert Scheifler <sunpitt!sun!ZERMATT.LCS.MIT.EDU!RWS>
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Yes, they do. Here's an example:
> d
#<DISPLAY psilocybin 0>
> (setf f (open-font d "vtsingle"))
#S(font id-internal 10485767 display #<DISPLAY psilocybin 0> reference-count 1 name "vtsingle" font-info-internal nil char-infos-internal nil local-only-p t)
> (text-extents f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
. . .
> (text-width f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
Is there any way to find out how wide a string is without doing any
CONSing?
Yes, and the current implementation doesn't (at least it didn't when I
tried it on a 36xx).
Given that TEXT-WIDTH destructively modifies the sequence that it's given, it
seems safer to recons before using it. Instead, I've defined my own function
that iterates over the sequence with CHAR-WIDTH.
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Both accept anything. What I guess you are really asking is why the
existing implementation of TRANSLATE-DEFAULT only does character to
index conversion for strings, as opposed to any sequence containing
characters. One answer is that I don't recall there being any real
resolution of how the default translation should work, or where it
should come from, but perhaps someone can set me straight.
Actually, I was asking why it appears that DRAW-GLYPH does not accept
characters as the ELT argument. How should I call it so that it does?
Below are example attempts. What issue(s) is/are there about the correct
handling of these attempts?
> root
#<window #524395>
> (setf g (create-gcontext :drawable w :font f :function boole-xor))
#S(gcontext id 10485769 display #<DISPLAY psilocybin 0> drawable #<window #10485768> cache-p t server-state #<Simple-Vector t 27 7FC723> local-state #<Simple-Vector t 27 7FC793>)
> (draw-glyph w g 50 50 65)
t
nil
> (draw-glyph w g 50 50 #\A)
>>Error: #\A should be of type INTEGER
. . .
> (draw-glyph w g 50 50 #\A :translate nil)
>>Error: #\A should be of type INTEGER
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Because no one has provided an implementation of BUFFER-READ-DEFAULT
for Lucid that handles timeouts.
One could at least specialize the case where TIMEOUT is 0, which I
would guess to be a somewhat comment case, using the same idea as my
EVENTS-PENDING-P function:
(defun events-pending-p (display)
"Returns T iff there are events pending on display, otherwise NIL."
(and (or (xlib::display-event-queue display)
(progn (display-finish-output display)
(xlib::display-event-queue display)))
t))
Recently, I also asked about using PROCESS-EVENT to get the
functionality of X V10's XUpdateMouse. My understanding of the
responses is that I misunderstood how PROCESS-EVENTS worked. Now I
think that I have a better understanding, but it seems to me that in
implementing this functionality, that is, nuking all pointer-motion
events and returning the coordinates of the last one, I will have to
iterate down the event queue once for each such event. Is there
anyway to search down the queue, leaving most events, but removing
some? Since the function would presumeably be called in an inner loop
of some motion handling facility, efficiency seems fairly important.
It seems to me that to do this efficiently, I have to grab the
event-queue myself, but hopefully I'm just still not understanding
PROCESS-EVENT fully (?) What are the arguments for not making the CLX
interface to the event-queue be the seemingly obvious sequence of
event objects?
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂07-Jan-88 1436 CL-Windows-mailer Re: more clx questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 14:36:17 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 112127; Thu 7-Jan-88 17:39:28 EST
Date: Thu, 7 Jan 88 17:39 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more clx questions
To: sunpitt!eti!psilocybin!rick@Sun.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <8801071929.AA03252@psilocybin.sun.com>
Message-ID: <880107173925.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 7 Jan 88 14:29:05 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Yes, they do. Here's an example:
No, they don't (don't we sound like little kids? :-) First, you seem to
be making a statement about the implementation. The documentation
(admittedly skimpy) makes no mention of destructive modification. It
is useful when you start talking about something to be clear about
how you made your deductions, since the documentation and implementation
are seldom isomorphic. In the case at hand, if you stare at the error
message:
> (text-extents f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
you will probably realize that "foo" probably isn't an array of
(UNSIGNED-BYTE 16), so that "foo" isn't being stored into. The problem
here is simply that the V11R1 implementation had an inconsistent
application of the default translation function (i.e. some routines
applied it, some didn't). It so happens that text-extents in V11R1
isn't applying any default translation. This bug has been fixed for
V11R2. In the meantime, if you supply XLIB::TRANSLATE-DEFAULT
explicitly, the code will be happier.
Actually, I was asking why it appears that DRAW-GLYPH does not accept
characters as the ELT argument. How should I call it so that it does?
Well, the V11R1 code as supplied won't let you. This will probably
get fixed for V11R2.
Is there
anyway to search down the queue, leaving most events, but removing
some?
Yes, just have the appropriate cases return nil with :discard-p nil.
The event functions have also been fixed to allow recursive calls,
which also makes things easier.
What are the arguments for not making the CLX
interface to the event-queue be the seemingly obvious sequence of
event objects?
Because then you either have to cons (undesirable) or worry about
alloc/free of resource objects (also undesirable). Also, event-case
allows the possibility of open-coding and extracting only those
components actually required. Also, you have to cons the sequence, or
otherwise contrain the internal event queue allocation mechanism. Also,
parts of the sequence are out on the network, not in memory.
∂12-Jan-88 1023 CL-Windows-mailer Change of address
Received: from emx.utexas.edu ([128.83.1.33]) by SAIL.Stanford.EDU with TCP; 12 Jan 88 10:23:40 PST
Date: Tue, 12 Jan 88 12:23:51 CST
From: ravi@emx.utexas.edu (Ravindra N. Rao)
Posted-Date: Tue, 12 Jan 88 12:23:51 CST
Message-Id: <8801121823.AA09958@emx.utexas.edu>
Received: by emx.utexas.edu (5.54/5.51)
id AA09958; Tue, 12 Jan 88 12:23:51 CST
To: cl-windows@sail.stanford.edu
Subject: Change of address
The host, ngp.utexas.edu on which I used to receive cl-windows mail has
been taken out of service. My new e-mail path is
ravi@emx.utexas.edu
The internet number for this host is 128.83.1.33. This is a new host
and very likely not registerd with sri-nic yet. Thanks.
Ravindra Rao.
∂15-Jan-88 0833 CL-Windows-mailer CLX child coordinate bug
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 08:33:16 PST
Date: 15 Jan 1988 11:01-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Subject: CLX child coordinate bug
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <569260919/rfb@SPICE.CS.CMU.EDU>
I sent this to XPERT, but forgot to put a copy here. I tried making
minor changes to CHANGE-DRAWABLE-GEOMETRY, but wasn't able to get
anything to work. I *really* need to be able to do this and I really
hope that I don't have to wait until XV11R2 or use C call-out if I can
avoid it. If anyone has a solution or even a good educated guess as to
how I can make this work, *please* let me know.
Rick
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date: Tue, 12 Jan 88 14:52:55 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
To: sunpitt!sun!athena.mit.edu!xpert@Sun.COM
Subject: CLX bug
VERSION:
X11 release 1
SYNOPSIS:
It is not possible to set the position of a window within its parent to
be a negative value using the CLX interface.
DESCRIPTION:
The setf forms for DRAWABLE-X and DRAWABLE-Y expect a value whose type
is CARD32, which is DEFTYPEd to be (UNSIGNED-BYTE 32). Therefore when
a negative integer is used, an error is signaled: ``X-Error: -10 isn't
card32''
REPEAT-BY:
Use CREATE-WINDOW to make a child, CHILD, of a root window.
Evaluate (SETF (DRAWABLE-X CHILD) -10)
FIX:
I would guess that a fix might be to change the CARD32 in the last
form of the CHANGE-DRAWABLE-GEOMETRY definition to be INT16 as is
stated in the January 1987 ``near-release'' of the protocol
specification for the ConfigureWindow request. However, from a quick
look at the code, I would guess that this would allow an application
to set DRAWABLE-WIDTH and DRAWABLE-HEIGHT to negative values as well.
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂18-Jan-88 2101 CL-Windows-mailer help for LISP on SUNs
Received: from space-tech.arpa by SAIL.Stanford.EDU with TCP; 18 Jan 88 21:00:52 PST
Date: 18 Jan 88 22:46:00 CST
From: "Ed Komp" <komp@space-tech.arpa>
Subject: help for LISP on SUNs
To: "cl-windows" <cl-windows@sail.stanford.edu>
Reply-To: "Ed Komp" <komp@space-tech.arpa>
I am not sure that this is the proper place for this request,
but it seems likely that there will be people on this list that
have answers to my questions.
I have a package currently running on DEC VAXstations, and am in the
process of porting it to the SUN.
I am not ready to go for "X" right now because of a very tight deadline.
So, I am interested in contacting individuals with experience
writing applications for SUN workstations in LISP
using the Window Toolkit.
I have questions about tuning the memory management for good performance,
what works well (AND what doesn't), general implementation hints, etc.
thanks very much,
ed komp
------
∂19-Jan-88 1016 CL-Windows-mailer Re: Post conference reflection - object-oriented toolkit
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 10:16:10 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae10635; 19 Jan 88 12:36 EST
Received: from csc.ti.com by RELAY.CS.NET id af15849; 19 Jan 88 12:31 EST
Received: from dsg by tilde id AA19222; Tue, 19 Jan 88 10:49:31 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 19 Jan 88 10:51:43 CST
Message-Id: <2778598189-938917@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Tue, 19 Jan 88 10:49:49 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Len%AIP1%TSD@atc.bendix.com
Cc: <chu%tsd%atc.bendix.com@RELAY.CS.NET>, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Subject: Re: Post conference reflection - object-oriented toolkit
In-Reply-To: Msg of Mon, 18 Jan 88 14:14 EDT from Len%AIP1%TSD@atc.bendix.com
> Regarding the future direction of X, I have but one concern. The
> structure of the Xtk toolkit is clearly evolving toward the
> object-oriented design approach. This, I believe, is a natural and
> very produtive apporach. Yet all widgets are written in vanilla C
> with some conventions adopted. NO object-oriented language support is
> available. I fear that this will cost dearly in the long run.
> ...
> Without an object-oriented language, all manipulation of the objects
> must be done using unenforcable conventions. The syntax is cluttered
> and may become unmaintainable. With an object-oriented language,
> object manipulation become natural and fairly painless. Many possible
> extensions become easier: debugging at object level, storing and
> loading object from databases, garbage collection of unused objects,
> and multiple inheritances.
> ...
> I strongly urge the Xtk toolkit developers to consider this issue.
> The views of others who've done object-oriented programming is also
> very welcome. Speaking personally, this issue is strongly
> discouraging me from using the Xtk toolkit.
> S. Chu <chu%tsd%atc.bendix.com@relay.cs.net>
I heartily concur. I'd like to point out the special implication for CLX users
who program X applications in Common Lisp: callout to a foreign-function Xtk
library is a sandtrap. It may look like a quick way out now, but it won't be
long before you'll wish you were using the standard CLOS OOPS like everybody
else. Then, you'll find that the half of the Xtk machinery which is devoted to
simulating an OOPS will be unnecessary.
∂19-Jan-88 1125 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 11:25:31 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab12006; 19 Jan 88 14:07 EST
Received: from csc.ti.com by RELAY.CS.NET id ac16367; 19 Jan 88 14:01 EST
Received: from SI by tilde id AA20764; Tue, 19 Jan 88 11:57:58 CST
Message-Id: <2778602234-797592@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 19 Jan 88 11:57:14 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX and Lowercase Alphabetic Keysyms
I've been implementing the keycode->character function for the
clx-extensions and ran into a problem:
Background:
Keycodes (from an event) are translated to keysyms (from the
keyboard-mapping supplied by the server) in the keycode->keysym
function. One of the parameters to keycode->keysym is the
keysym-index, which is essentially the shift-state, and is computed by
the keysym-index function based on the modifier-state and an
indication of whether or not the keysym is both-case alphabetic.
(The caps-lock key only shifts both-case alphabetic keys.)
The define-keysym function provides a mapping from keysyms to
arbitrary lisp objects and keysym-translate functions. Once a keycode
is translated to a keysym, the keysym is translated to an object by
looking up the object associated with the keysym and calling the
associated keysym-translate function with the display, object and
modifier state. The keysym-translate function merges the modifier
state with the object. The result is returned by keycode->character.
The keyboard-mapping returned by the X server doesn't contain the
keysyms for lower-case alphabetic keys (see chapter 6 of the X Window
System Protocol document).
Problems:
1. Because the keyboard-mapping doesn't include lowercase keysyms,
keycode->keysym returns uppercase keysyms for lowercase keys.
There is no keysym-downcase function.
2. In order to interpret the caps-lock modifier, its necessary to have
a keysym-both-case-p predicate, which doesn't exist.
3. Character case isn't passed in to the keysym-translate function,
so it must be re-computed, which is both inefficient and possibly
inconsistent with the computation in keysym-index. Also, in order
for an application to change the details of how the lock modifier
affects control keys and such, all the character translations must
change.
4. Define-keysym maps keysyms to arbitrary lisp objects. It's not
possible to downcase arbitrary objects, or apply control/meta
modifiers so specialized keysym-translate functions are required.
5. A define-keysym with a lowercase keysym will never be used, because
the server keyboard-mapping may not contain them.
To fix:
Either:
Define a new bit in the modifier state ":caps" for use in the
modifier-state passed into the keysym-translate function. This
would be set when (ODDP keysym-index) [The keysym-index convention
is that 0 is for unshifted and 1 is shifted. It may be 2 or 3 if
the keyboard-mapping contains more than one character set].
This localizes shift-lock computations to the keysym-index
function. The meaning of the :caps bit is "this keysym is shifted"
by some combination of the other modifiers. The make-state-mask
and make-state-keys functions would be modified to know about the
:caps bit.
OR:
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
[This is the solution I prefer. Does anyone know WHY X doesn't put
lowercase keysyms in the keyboard-mapping? If this is actually
useful, then perhaps hiding the convention isn't a good idea and
the :caps bit proposal would be better.]
IN ADDITION, define a keysym-both-case-p predicate and modify
define-keysym as follows:
(defun define-keysym (object keysym &key modifiers mask display
lowercase
(translate #'default-keysym-translate))
;; Define the translation from keysym/modifiers to a (usually
;; character) object.
;;
;; MODIFIERS is either a modifier-mask or list containing intermixed
;; keysyms and state-mask-keys specifying when to use this
;; keysym-translation.
;;
;; MASK is either a modifier-mask or list containing intermixed
;; keysyms and state-mask-keys specifying which modifiers to look at
;; (i.e. modifiers not specified are don't-cares)
;;
;; If DISPLAY is specified, the translation will be local to DISPLAY,
;; otherwise it will be the default translation for all displays.
;;
;; LOWERCASE is used for uppercase alphabetic keysyms. The value
;; is the associated lowercase keysym. This information is used
;; by the keysym-both-case-p predicate (for caps-lock computations)
;; and by the keysym-downcase function.
;;
;; TRANSLATE will be called with parameters (display state OBJECT)
;; when translating KEYSYM and modifiers and mask are satisfied.
;; [e.g (zerop (logxor (logand state (or mask -1)) (or modifiers 0)))
;; when mask and modifiers aren't lists of keysyms]
;;
(declare (type (or string-char t) object)
(type keysym keysym)
(type (or null state-mask (list (or keysym state-mask-key)))
modifiers mask)
(type (or null display) display)
(type (or null keysym) lowercase)
(type (function (display card16 t) t) translate)))
Comments? Does anyone have another proposal? Please respond in time for
me to complete the implementation before the Feb 1 release 2 cutoff.
-LaMott
P.S. Isn't it amazing how complicated character translation can get?
∂19-Jan-88 1217 CL-Windows-mailer help for LISP on SUNs
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 12:16:54 PST
Received: by labrea.Stanford.EDU; Tue, 19 Jan 88 12:17:00 PST
Received: from rainbow-warrior.lucid.com by edsel id AA11180g; Tue, 19 Jan 88 12:08:42 PST
Received: by rainbow-warrior id AA09113g; Tue, 19 Jan 88 12:11:21 PST
Date: Tue, 19 Jan 88 12:11:21 PST
From: Zachary Smith <edsel!zach@labrea.Stanford.EDU>
Message-Id: <8801192011.AA09113@rainbow-warrior.lucid.com>
To: labrea!komp@SPACE-TECH.ARPA
Cc: cl-windows@sail.stanford.edu
In-Reply-To: "Ed Komp"'s message of 18 Jan 88 22:46:00 CST <8801190732.AA08517@edsel.lucid.com>
Subject: help for LISP on SUNs
I probably know as much as anyone else about what is possible and what isn't
on the Sun with the Window Toolkit. If you have window-specific questions you
are welcome to send them to me. I would be happy to help you out if I can.
z
∂19-Jan-88 2115 CL-Windows-mailer CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 21:15:44 PST
Received: from relay2.cs.net by RELAY.CS.NET id bm18988; 19 Jan 88 23:46 EST
Received: from csc.ti.com by RELAY.CS.NET id ad00302; 19 Jan 88 22:04 EST
Received: from home by tilde id AA00408; Tue, 19 Jan 88 19:36:09 CST
Received: from SI by home id AA25385; Tue, 19 Jan 88 17:06:03 CST
Message-Id: <2778620689-1906519@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX :force-output-p and event-listen
In-Reply-To: Msg of Tue, 12 Jan 88 07:34 EST from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> [I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
> should similarly be changed to force output only when blocking to wait
> for an event. Note that XLIB:EVENT-LISTEN already does not force
> output, which is consistent with the desired new semantics for
> XPending. - RWS]
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless. It seems to me that event-listen should either return a
boolean, or always listen-for and queue new events (making it more
expensive). Returning a boolean would be more consistent with the
common-lisp listen function, while returning a number gives more
information. Is it ever necessary to know how much greater than one the
event list is? Which would you do?
When event-case and process-event are called recursively, they don't
look at events that have been previously processed, but not
deleted. It seems to me that event-listen should do the same.
I'll make this change, unless someone objects.
∂20-Jan-88 0805 CL-Windows-mailer CLX questions
Received: from aai1 ([128.18.4.91]) by SAIL.Stanford.EDU with TCP; 20 Jan 88 08:05:07 PST
Received: from localhost by aai1 (3.2/5.00)
id AA03910 for cl-windows@sail.stanford.edu; Wed, 20 Jan 88 08:03:35 PST
Message-Id: <8801201603.AA03910@aai1>
To: cl-windows@sail.stanford.edu
Organization: SRI International, Menlo Park, CA
Phone: Office--415/859-3759 Home--415/364-2221
Subject: CLX questions
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
I have a couple of questions:
1. Can anyone tell me the status of the standardization comittee's
work on defining a common lisp window standard?
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
The two reasons I can think of are increased edification (intellectual,
not moral, although using it probably builds character!) and having
something that works with X *today*.
3. How close is clx to being finalized? How successful have people been
in using it? (I know there are some people on the xpert mailing list
discussing it.) What sort of things are possible with it, with minimum
difficulty, e.g., menus, buttons, all the standard sort of stuff?
Any feedback will be appreciated.
Marie Bienkowski
bienk@istc.sri.com
∂21-Jan-88 1851 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 18:51:13 PST
Date: 21 Jan 1988 21:17-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Subject: Re: CLX :force-output-p and event-listen
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <569816261/rfb@SPICE.CS.CMU.EDU>
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
Sounds right to me.
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless.
I agree, the ``extra information'' isn't accurate and therefore
potentially misleading. I vote for making EVENT-LISTEN a simple
predicate by default and possibly accepting some keyword argument(s)
which make it do otherwise.
BTW Why are the values for :OVERRIDE-REDIRECT :ON and :OFF instead of T
and NIL?
Rick Busdiecker
Expert Technologies, Inc.
sunpitt!eti!rick@eti.com
or
rfb@cs.cmu.edu
∂22-Jan-88 1644 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Jan 88 16:43:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id af04412; 22 Jan 88 17:22 EST
Received: from csc.ti.com by RELAY.CS.NET id ab18438; 22 Jan 88 17:11 EST
Received: from SI by tilde id AA18090; Fri, 22 Jan 88 12:42:48 CST
Message-Id: <2778864099-4249948@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 22 Jan 88 12:41:39 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: CL-Windows@SAIL.STANFORD.EDU
Subject: Re: CLX :force-output-p and event-listen
In-Reply-To: Msg of 21 Jan 1988 21:17-EST from Rick.Busdiecker@SPICE.CS.CMU.EDU
BTW Why are the values for :OVERRIDE-REDIRECT :ON and :OFF instead of T
and NIL?
This was discussed during the CLX design. Here's part of the discussion:
------- Forwarded Message
Date: Sat, 2 May 87 11:10 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: NIL in CLX
To: cl-windows@sail.stanford.edu
A few people have said they would prefer the gcontext accessors to
signal an error rather than return the "wrong" value. After I thought
about this, I finally realized what was meant. The original plan I had
for gcontext components was that NIL was never a legal value. This is
true of everything but (I see now) the clip-mask, for which an empty
sequence is legal (if unusual, since it effectively disables all
graphics output, which is different from :none, which is a full-drawable
clip). [An empty dashes sequence is not legal.] My intent was that
accessors would return NIL to indicate "unknown", rather than
signalling, because checking for NIL seems more convenient than handling
signals.
Note that even if a gcontext has caching enabled, it won't always be
possible for the accessors to return a correct value. This is true of
the default tile, stipple, and font values (I suppose :default could be
returned, but I don't really think setf should accept :default), but
also any copying from an uncached to a cached gc will "infect"
components of the cached gc with unknown values.
Related to this is the fact that I have defined create-window,
create-gc, and with-gc (and others) so that passing a keyword argument
as NIL is the same as not passing it. That is, NIL means "ignore me".
I thought this was important for create-window and create-gc, because I
have been burned by wanting to provide a function at a higher level that
accepts some or all of the same keyword arguments, and then pass them
down; either you have to propagate knowledge of default values, or you
have to use a rest argument or some other hackery. Making a few values
:on, :off, and :none seemed worth it to preserve NIL as an ignore value.
I would like to hear comments on all of this. Is it useful to retain
NIL as "ignore" and "unknown"? The void clip-mask is the only conflict
that I can see. If these uses of NIL are removed, then all instances of
:none could be changed to NIL except in clip-mask, and all instances of
(member :on :off) could be changed to boolean, and presumably gcontext
accessors would be defined to signal for unknown components.
------- End of Forwarded Message
∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:06:13 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116177; Sat 23-Jan-88 11:10:09 EST
Date: Sat, 23 Jan 88 11:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX and Lowercase Alphabetic Keysyms
To: Oren@home.csc.ti.com, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778602234-797592@SI>
Message-ID: <880123110611.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 12:57 EST
From: LaMott Oren <Oren@home.csc.ti.com>
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
Sounds fine with me.
Does anyone know WHY X doesn't put lowercase keysyms in the
keyboard-mapping?
It doesn't *require* the lowercase keysyms, which isn't the same as
outlawing them. Not requiring them allows the server to provide an
"exact" representation of the physical engravings on the key. Some
people viewed that as desirable, and the belief is that if clients have
sufficient knowledge to "understand" the keysym, then they will have
enough to understand case transformation.
∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:06:40 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116178; Sat 23-Jan-88 11:10:27 EST
Date: Sat, 23 Jan 88 11:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX and Lowercase Alphabetic Keysyms
To: Oren%home.csc.ti.com@relay.cs.net, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778602234-797592@SI>
Message-ID: <880123110638.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 12:57 EST
From: LaMott Oren <Oren@home.csc.ti.com>
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
Sounds fine with me.
Does anyone know WHY X doesn't put lowercase keysyms in the
keyboard-mapping?
It doesn't *require* the lowercase keysyms, which isn't the same as
outlawing them. Not requiring them allows the server to provide an
"exact" representation of the physical engravings on the key. Some
people viewed that as desirable, and the belief is that if clients have
sufficient knowledge to "understand" the keysym, then they will have
enough to understand case transformation.
∂23-Jan-88 0828 CL-Windows-mailer CLX :force-output-p and event-listen
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:28:06 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116185; Sat 23-Jan-88 11:32:03 EST
Date: Sat, 23 Jan 88 11:27 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX :force-output-p and event-listen
To: Oren%home.csc.ti.com@relay.cs.net, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778620689-1906519@SI>
Message-ID: <880123112752.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
> [I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
> should similarly be changed to force output only when blocking to wait
> for an event.
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
I suppose it might depend on whether you think the normal case is for a
single process to mix input and output, or whether you will have a
separate process reading the events. Also, the non-forcing case can be
viewed as a convenient way to not have to do an event-listen first. I
don't have a very strong opinion either way, which leans to leaving it
as is.
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless.
This just seems like an implementation detail/defect.
It seems to me that event-listen should either return a
boolean, or always listen-for and queue new events (making it more
expensive).
I would say it is acceptable for event-listen to work as follows: if
there are already locally queued events, return that number, else wait
within the timeout for an event, but read as many as possible at that
time. This makes a count meaningful without making it always expensive.
When event-case and process-event are called recursively, they don't
look at events that have been previously processed, but not
deleted. It seems to me that event-listen should do the same.
Yes.
∂23-Jan-88 0931 CL-Windows-mailer CLX questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 09:31:09 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116193; Sat 23-Jan-88 12:35:08 EST
Date: Sat, 23 Jan 88 12:31 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX questions
To: bienk@spam.istc.sri.com, cl-windows@sail.stanford.edu
In-Reply-To: <8801201603.AA03910@aai1>
Message-ID: <880123123120.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
Whether something "replaces" CLX depends on how encompassing you thing a
"toolkit" is. As an example, the C Xtk toolkit does not attempt to
provide a graphics interface (although it does provide for some graphics
context management), it leaves the widget writer to use the standard C
Xlib graphics calls. The Andrew toolkit, on the other hand, provides
(mandates) its own graphics interface; this approach can be troublesome
if the interface does not provide the full functionality of the
underlying system.
3. How close is clx to being finalized?
What is there in release 1 is reasonably solid. There is more coming,
that has been discussed on this list. I believe what will pull together
for release 2 will still need a few months review.
How successful have people been
in using it?
I use it all the time (almost exclusively) for debugging servers.
What sort of things are possible with it, with minimum
difficulty, e.g., menus, buttons, all the standard sort of stuff?
All that "stuff" sounds like toolkit stuff, and you won't find it in CLX.
∂23-Jan-88 1329 CL-Windows-mailer CLX questions
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jan 88 13:29:04 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 327066; Sat 23-Jan-88 16:28:25 EST
Date: Sat, 23 Jan 88 16:28 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLX questions
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, bienk@spam.istc.sri.com
cc: cl-windows@sail.stanford.edu
In-Reply-To: <880123123120.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <19880123212813.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: Sat, 23 Jan 88 12:31 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
Whether something "replaces" CLX depends on how encompassing you thing a
"toolkit" is.
CLUE should be implemented using CLX. Therefore, even if no one other
than the CLUE implementers ever programs in CLX, its benefit remains.
Furthermore, it allows a multitude of other toolkits to be investigated.
∂24-Jan-88 1337 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from ATHENA (ATHENA.MIT.EDU) by SAIL.Stanford.EDU with TCP; 24 Jan 88 13:36:44 PST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27719; Sun, 24 Jan 88 16:36:21 EST
Received: by JASON.MIT.EDU (5.45/4.7) id AA10317; Sun, 24 Jan 88 15:23:30 EST
Message-Id: <8801242023.AA10317@JASON.MIT.EDU>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Your message of Tue, 19 Jan 88 11:57:14 -0600.
<2778602234-797592@SI>
Date: Sun, 24 Jan 88 15:23:27 EST
From: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>
This problem is handled by C XLIB in a reasonable and efficient way.
The first time the keyboard-mapping is needed, it is requested from
the server and then it is modified to replace entries like (90 0)
by (122 90). Why not use this approach ?
Roman.
∂24-Jan-88 1545 CL-Windows-mailer Ignored values
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 15:45:29 PST
Date: 24 Jan 1988 18:43-EST
From: Steve.Handerson@SPICE.CS.CMU.EDU
To: cl-windows@sail.stanford.edu
Subject: Ignored values
Message-Id: <570066203/skh@SPICE.CS.CMU.EDU>
How about making NIL be false and having the parameter's
default be :undefined?
Similarly, why not put :ignore in slots of things you
don't want inherited?
Yes, it's unfortunate that NIL means so many things.
It tends to be confusing.
-- Steve
∂24-Jan-88 1615 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 16:15:31 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA27212; Sun, 24 Jan 88 16:16:13 PST
Received: from frozen by franz (5.5/3.14)
id AA05735; Sun, 24 Jan 88 15:49:09 PST
Received: by frozen (3.2/3.14)
id AA02798; Sun, 24 Jan 88 15:42:39 PST
Return-Path: <frozen!jdi>
Message-Id: <8801242342.AA02798@frozen>
To: Roman J. Budzianowski <ATHENA.MIT.EDU!roman@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Your message of Sun, 24 Jan 88 15:23:27 EST.
<8801242023.AA10317@JASON.MIT.EDU>
Date: Sun, 24 Jan 88 15:42:38 PST
From: John Irwin <franz!frozen!jdi@ucbarpa.Berkeley.EDU>
Right after you open the display, do:
(setq *X-keysyms* (xlib:keyboard-mapping x-display))
(do* ((i (xlib:display-min-keycode x-display) (1+ i))
(max (xlib:display-max-keycode x-display))
(one (aref *X-keysyms* i 0) (if (<= i max) (aref *X-keysyms* i 0)))
(two (aref *X-keysyms* i 1) (if (<= i max) (aref *X-keysyms* i 1))))
((> i max))
(cond ((and (<= one #x5a) (>= one #x41) (zerop two))
(setf (aref *X-keysyms* i 1) one)
(setf (aref *X-keysyms* i 0) (+ one 32)))
((and (plusp (logand one #xff00)) (zerop two))
(setf (aref *X-keysyms* i 1) one))))
Note that the second part of the cond isn't neccessary to map lower case
correctly, it just handles special keys.
-- John (jdi%franz.UUCP@ucbarpa.Berkeley.EDU)
--------
Your message:
This problem is handled by C XLIB in a reasonable and efficient way.
The first time the keyboard-mapping is needed, it is requested from
the server and then it is modified to replace entries like (90 0)
by (122 90). Why not use this approach ?
Roman.
--------
∂25-Jan-88 1250 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 12:47:30 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab16033; 25 Jan 88 14:28 EST
Received: from csc.ti.com by RELAY.CS.NET id aj07230; 25 Jan 88 14:14 EST
Received: from SI by tilde id AA24464; Mon, 25 Jan 88 12:48:31 CST
Message-Id: <2779123632-3327935@SI>
Sender: OREN@si.csc.ti.com
Date: Mon, 25 Jan 88 12:47:12 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: John Irwin <franz!frozen!jdi@UCBARPA.BERKELEY.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Msg of Sun, 24 Jan 88 15:42:38 PST from John Irwin <franz!frozen!jdi@ucbarpa.berkeley.edu>
Right after you open the display, do:
...
(setf (aref *X-keysyms* i 0) (+ one 32)))
...
This isn't general enough to handle arbitrary keymaps (for an example,
see the Cryllic keysyms). That's why I proposed having a :lowercase
parameter on the define-keysym function. However, it may be a good
idea to fix-up the keyboard mapping once, instead of dealing with it on
every keystroke.
Thanks for the response.
LaMott
∂25-Jan-88 1649 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:48:53 PST
Received: from relay2.cs.net by RELAY.CS.NET id ag18896; 25 Jan 88 17:34 EST
Received: from csc.ti.com by RELAY.CS.NET id aj07944; 25 Jan 88 17:11 EST
Received: from dsg by tilde id AA28690; Mon, 25 Jan 88 15:58:01 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Jan 88 11:19:15 CST
Message-Id: <2779118322-14245288@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Mon, 25 Jan 88 11:18:42 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX :force-output-p and event-listen
In-Reply-To: Msg of Tue, 19 Jan 88 17:04:49 CST from LaMott Oren <Oren@home.csc.ti.com>
> It seems to me that with this change, :force-output-p should default
> to T in both process-event and event-case. What do you think?
Agreed.
> Also, the current implementation of event-listen doesn't go and read
> new events when there are events queued, making counts above zero
> meaningless. It seems to me that event-listen should either return a
> boolean, or always listen-for and queue new events (making it more
> expensive). Returning a boolean would be more consistent with the
> common-lisp listen function, while returning a number gives more
> information. Is it ever necessary to know how much greater than one
> the event list is? Which would you do?
I'd prefer to make event-listen an inexpensive boolean.
> When event-case and process-event are called recursively, they don't
> look at events that have been previously processed, but not deleted.
> It seems to me that event-listen should do the same. I'll make this
> change, unless someone objects.
No objection here.
∂25-Jan-88 1650 CL-Windows-mailer Re: Comments on CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:50:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id aq18896; 25 Jan 88 17:35 EST
Received: from csc.ti.com by RELAY.CS.NET id an07944; 25 Jan 88 17:12 EST
Received: from dsg by tilde id AA28856; Mon, 25 Jan 88 16:02:14 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Jan 88 14:30:08 CST
Message-Id: <2779129778-14933568@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Mon, 25 Jan 88 14:29:38 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Comments on CLUE
In-Reply-To: Msg of 4 Jan 1988 14:44-EST from Rick.Busdiecker@spice.cs.cmu.edu
Thanks for your review. Sorry that it's taken so long to reply, but things have
been busy here in CLUEland, as we prepare to make prototype code publicly
available. Was it Colonel Mustard in the cloak room with the drill press? Stay
tuned.
> Mostly I think that CLUE is an attempt to standardize too much too
> soon.
I share your misgivings about premature standardization of UI sw; CLUE, too,
salutes the "policy-free" approach. And CLUE is just one proposed mechanism. I
agree that standardization will not really take place until some proposal has
acquired enough experience and review to motivate lots of people to adopt it.
That's why we're very interested in learning specifically where you think CLUE
is "too much" or is lacking.
> Why is it that the default CONTACT class, which has over 70 slots,...
This is a common misconception, which the next document ought to work harder to
prevent. Most of the stuff in the defcontact form are resource declarations. In
fact, the contact class has 2 class slots and 14 instance variables (of which 8
are "shadow" copies of X window attributes).
> In specifying my own class hierarchy, I didn't see any need to make a
> distinct classes for composite and non-composite objects although I
> considered it at first.
We, too, considered both alternatives. The chief argument in favor of a distinct
composite class is that, at the contact level, parenthood implies a geometry
mgmt responsibility. Indeed, it was argued that geometry mgmt could reside
nowhere but in the parent contact. But geometry mgmt is too heavy a burden for
all contacts to carry; hence, the composite class.
> Why is the form DEFCONTACT used rather than DEFCLASS?
DEFCONTACT wraps extra processing related to resources around DEFCLASS.
> DEFCONTACT should not be using ``the property list of the class name
> symbol to store information about the resources needed by instances of
> the class.'' CLOS classes are first-class, specializable objects so
> there's no need for such plist hacks.
Good point. This is really an implementation-specific detail. The document will
be changed to allow other non-plist implementations.
> In general, I would have guessed that having specializable generic
> functions with names like BUTTON-PRESS, etc. and which accepted
> keyword arguments like those passed to the CLX event handling function
> would have been a better approach than the mechanism proposed in CLUE.
> To specialize event handling, one might define a sub-class of WINDOW
> named BUTTON which specialized ENTER-WINDOW, BUTTON-PRESS, etc. to
> invoke other g.f.'s with names like ACTIVATE-BUTTON, SELECT-BUTTON,
> FIRE-BUTTON, etc.
There are three advantages to the CLUE approach. First, better consolidation of
event dispatching. More often than not, proper handling of an event depends on
more than just the event type (e.g. also which key or pointer button). CLUE
event specs provide a way to express these more specific conditions. Second,
the possible event types handled by a contact are not fixed at compile-time.
I'm free to have one instance of class C react to pointer input, while all other
C instances do not. And I don't have to define a dummy BUTTON-PRESS method for
C "just in case". Third, event translation (i.e. the binding of an event type
to the function which will process it, for a specific instance) is not
determined at compile-time, but dynamically instead. This allows for event
translations to be read as resources when a contact is initialized, for
individual contacts to add new keystroke bindings, and for event translations to
change to reflect dynamic contact state (a common requirement).
> Why is there :UP, but not :DOWN?
No good reason. :UP is sorta wimpy, since it's only an abbreviation for the
equally-simple :KEY-RELEASE form. It's an example of how to use the general spec
list capability. :DOWN would be equally trivial to implement.
> However even if the CLUE approach to event handling is adopted, I
> don't see the desireability of specifying an association list. Mostly
> this is because of my desire to avoid using lists whenever there's a
> clean efficient alternative.
Fine. The intent was that a non-alist implementation of event-translation should
be possible. The document needs some changes to make this clear.
> I think that what this chapter points out the need for the Common Lisp
> standard to specify a bit more about what streams are and how one goes
> about creating new kinds of streams. Having this all be
> implementation dependant is a real pain (especially when using
> implementations like Lucid which insist on hiding as much of their
> internals as possible!)
Agreed. Mike McMahon <MMcM@scrc-stony-brook.arpa> and others have begun some
work in this area.
∂26-Jan-88 0048 CL-Windows-mailer Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 00:48:33 PST
Date: 26 Jan 1988 03:12-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570183177/rfb@SPICE.CS.CMU.EDU>
Date: Mon, 25 Jan 88 14:29:38 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
. . .
> In general, I would have guessed that having specializable generic
> functions with names like BUTTON-PRESS, etc. and which accepted
> keyword arguments like those passed to the CLX event handling function
> would have been a better approach than the mechanism proposed in CLUE.
> To specialize event handling, one might define a sub-class of WINDOW
> named BUTTON which specialized ENTER-WINDOW, BUTTON-PRESS, etc. to
> invoke other g.f.'s with names like ACTIVATE-BUTTON, SELECT-BUTTON,
> FIRE-BUTTON, etc.
There are three advantages to the CLUE approach. First, better consolidation of
event dispatching. More often than not, proper handling of an event depends on
more than just the event type (e.g. also which key or pointer button). CLUE
event specs provide a way to express these more specific conditions. Second,
the possible event types handled by a contact are not fixed at compile-time.
I'm free to have one instance of class C react to pointer input, while all other
C instances do not. And I don't have to define a dummy BUTTON-PRESS method for
C "just in case". Third, event translation (i.e. the binding of an event type
to the function which will process it, for a specific instance) is not
determined at compile-time, but dynamically instead. This allows for event
translations to be read as resources when a contact is initialized, for
individual contacts to add new keystroke bindings, and for event translations to
change to reflect dynamic contact state (a common requirement).
I think that there are many classes which one might want to define in a
toolkit which don't require this degree of flexibility. For cases
where the flexibility is desired, the added functionality (and
performance cost) as needed. For example, an EDITOR-WINDOW might
define a KEY-PRESS which made use of its KEYMAP. In my toolkit, an
ACTION-BUTTON is a BUTTON whose FIRE-BUTTON method FUNCALLs its ACTION
slot, but most BUTTONs will be expected to cause the same action
throughout their existance so that action is defined using DEFMETHOD
and is fixed at compile time.
The ability to have one C instance which acts just slightly differently
can be had at the cost of specializing C for that instance. I think
that this class specialization more accurately reflects the semantics
of the situation since the ``special instance'' has slightly different
properties than the other instances, unless pointer-sensistivity is
considered to be a boolean property of C instances in which case there
really needs to be the equivalent of a BUTTON-PRESS method defined for
C.
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂27-Jan-88 0921 CL-Windows-mailer CLX and Kyoto Common Lisp
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:20:55 PST
Date: Wed 27 Jan 88 11:22:17-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: CLX and Kyoto Common Lisp
To: cl-windows@SAIL.STANFORD.EDU
cc: lrc.bennett@R20.UTEXAS.EDU
Message-ID: <12369978670.26.LRC.OPPENHEIM@R20.UTEXAS.EDU>
We want to write applications using CLX which will be ported to a
UNIX-based PC. We want to compile the applications using Kyoto CL.
I'd appreciate getting in touch with people who have done something
similar to find out if it's feasible and what the difficulties are.
Thanks.
Jennifer Oppenheim
Linguistics Research Center
University of Texas, Austin
-------
∂27-Jan-88 1708 CL-Windows-mailer Re: Comments on CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 27 Jan 88 17:08:34 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae07294; 27 Jan 88 19:37 EST
Received: from csc.ti.com by RELAY.CS.NET id ad23228; 27 Jan 88 19:26 EST
Received: from dsg by tilde id AA17601; Wed, 27 Jan 88 16:24:03 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 27 Jan 88 16:22:34 CST
Message-Id: <2779306185-9017282@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Wed, 27 Jan 88 15:29:45 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU, Rick.Busdiecker@SPICE.CS.CMU.EDU
Subject: Re: Comments on CLUE
In-Reply-To: Msg of 4 Jan 1988 14:44-EST from Rick.Busdiecker@spice.cs.cmu.edu
> I also got the impression that a lot of the the (generic) functions
> proposed in CLUE are just arbitrary name changes which don't use
> ``conc-names'' so that they will have a high probability of causing
> all sorts of package conflicts which shouldn't be necessary. PRESENT
> vs. MAP-WINDOW is one example of what I'm talking about.
No, there's no intention to dictate arbitrary name changes. In particular, while
PRESENT and MAP-WINDOW are strongly related, they are distinct operations.
PRESENT, the "higher level" construct, does a bunch of CLUE-specific stuff in
addition to calling MAP-WINDOW.
Re ``conc-names'': here's an issue that has not been adequately addressed. I'd
like to hear everyone's opinion, because I believe it revolves around a question
of proper CLOS style/usage.
First of all, CLOS has changed a bit here: the :accessor-prefix and
:reader-prefix options of defclass are no longer defined. Instead, the
progammer must explicitly define a prefix as part of the :accessor/:reader slot
options for each slot.
It has been suggested that using prefixes in :accessor/:reader names is good
CLOS style.
Note also that a generic function, since it enforces an arglist convention for
all its methods, is not *absolutely* generic; there really is a bit of implicit
semantics there. Therefore, it's appropriate to use a prefix (which denotes the
"implicit semantics") for all generic function names.
So what should we do?
a. Use "<class-name>-" as the prefix for all slot :accessor/:reader
options.
b. Use "<class-name>-" as the prefix for all slot :initarg options.
c. Use "<class-name>-" as the prefix for all CLUE generic functions
(i.e. methods).
∂27-Jan-88 1832 CL-Windows-mailer Re: Comments on CLUE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 18:32:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330109; Wed 27-Jan-88 21:32:18 EST
Date: Wed, 27 Jan 88 21:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on CLUE
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: Rick.Busdiecker@CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2779306185-9017282@Sierra>
Message-ID: <19880128023218.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 27 Jan 88 15:29:45 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Re ``conc-names'': here's an issue that has not been adequately addressed. I'd
like to hear everyone's opinion, because I believe it revolves around a question
of proper CLOS style/usage.
First of all, CLOS has changed a bit here: the :accessor-prefix and
:reader-prefix options of defclass are no longer defined. Instead, the
progammer must explicitly define a prefix as part of the :accessor/:reader slot
options for each slot.
That's correct. CLOS endeavours not to promote any particular naming
convention, but to allow each programmer to choose his own. Of course it
would be a disaster if a bunch of programmers working on a single system,
such as the constellation of X-Windows tools, didn't come to an agreement
on a common naming convention. That's common sense. But CLOS didn't want
to force all the programmers in the universe to agree on a common naming
convention.
It has been suggested that using prefixes in :accessor/:reader names is good
CLOS style.
Particularly because it matches the style used by most Common Lisp built-in
functions.
Note also that a generic function, since it enforces an arglist convention for
all its methods, is not *absolutely* generic; there really is a bit of implicit
semantics there. Therefore, it's appropriate to use a prefix (which denotes the
"implicit semantics") for all generic function names.
So what should we do?
a. Use "<class-name>-" as the prefix for all slot :accessor/:reader
options.
b. Use "<class-name>-" as the prefix for all slot :initarg options.
c. Use "<class-name>-" as the prefix for all CLUE generic functions
(i.e. methods).
Note that the proper prefix is usually not the name of the particular class
you are defining, and often not the name of a class at all. The best
prefix is a name describing the whole family of classes that share the
"implicit semantics." Sometimes this is a name of a class that is a common
superclass of all the others, sometimes it is not. Usually it's a very
general word, like "window."
You should certainly use the same convention for a and c, because no one
should have to know whether a generic function they are calling has its
methods defined by defmethod or by :accessor/:reader/:writer slot-option.
I believe that the prefix-dash convention is the right one for a and c.
b is less clear, as is the related issue of whether initialization arguments
are best named with keyword symbols or regular symbols. This depends
primarily on whether you plan to have classes composed as mixtures of
superclasses contributed by very independent modules, or whether all the
classes mixed together will be closely coordinated and therefore can share
a single space of names. Prefixes on initialization arguments can get
awkward, so it's nice to avoid them if you can, but it isn't always
possible. I don't have much wisdom to offer here.
∂27-Jan-88 2103 CL-Windows-mailer mailing address
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:03:46 PST
Date: 28 Jan 1988 00:00-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Cc: Gripe@cs.cmu.edu
Subject: mailing address
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570344424/rfb@SPICE.CS.CMU.EDU>
Could someone give me the email address for either Lamott Oren or Kerry
Kimbrough. The addresses that I have:
LaMott Oren <Oren@home.csc.ti.com>
Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
bounce from CMU.
Rick
∂27-Jan-88 2129 CL-Windows-mailer Re: mailing address
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:29:16 PST
Received: from SPICE.CS.CMU.EDU by SPICE.CS.CMU.EDU; 28 Jan 88 00:29:05 EST
To: Rick.Busdiecker@cs.cmu.edu
cc: CL-Windows@Sail.Stanford.Edu , Gripe@cs.cmu.edu
Subject: Re: mailing address
In-reply-to: Your message of 28 Jan 88 00:00:00 -0500.
<570344424/rfb@SPICE.CS.CMU.EDU>
Date: Thu, 28 Jan 88 00:28:53 EST
Message-ID: <1867.570346133@SPICE.CS.CMU.EDU>
From: Christopher.Hoover@SPICE.CS.CMU.EDU
Rick,
In Lisp Pointers, I have Kerry Kimbrough's address listed as:
kibmbrough%dsg%ti-csl.csnet@csnet-relay
but I think that would bounce due to lack of a domain name. I would try:
kibmbrough%dsg%ti-csl.csnet@realy.cs.net
LaMott Oren's should follow the same transformation of course.
-- Chris.
∂27-Jan-88 2141 CL-Windows-mailer Re: Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:41:20 PST
Date: 28 Jan 1988 00:29-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>,
CL-Windows@Sail.Stanford.Edu
Subject: Re: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570346167/rfb@SPICE.CS.CMU.EDU>
Date: Wed, 27 Jan 88 21:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
b is less clear, as is the related issue of whether initialization arguments
are best named with keyword symbols or regular symbols. This depends
primarily on whether you plan to have classes composed as mixtures of
superclasses contributed by very independent modules, or whether all the
classes mixed together will be closely coordinated and therefore can share
a single space of names. Prefixes on initialization arguments can get
awkward, so it's nice to avoid them if you can, but it isn't always
possible. I don't have much wisdom to offer here.
I've been implementing a tool-kit using almost one package per class
and haven't had problems with slot names since I consider them to be
part of the package interface, i.e. exported symbols. A problem with
this is that I'm exporting symbols with names like X and Y which is
begging for conflicts. My solution has been to define a package which
represents the tool-kit as a whole which only the exports non-slot-name
symbols of the various packages which it uses. My idea is that an
application that is simply using the tools/classes, without defining or
specializing any of its own can just USE-PACKAGE this toolkit package.
An application which defines or specializes specific classes which are
part of the toolkit should define a new class in a new package which
only USE-PACKAGEs the packages which it actually uses in the class
definition.
Rick
∂27-Jan-88 2224 CL-Windows-mailer Re: mailing address
Received: from tut.cis.ohio-state.edu (ohio-state.arpa) by SAIL.Stanford.EDU with TCP; 27 Jan 88 22:21:48 PST
Received: by tut.cis.ohio-state.edu (5.54/0.2)
id AA08460; Thu, 28 Jan 88 01:20:28 EST
Message-Id: <8801280620.AA08460@tut.cis.ohio-state.edu>
Date: Thu 28 Jan 88 01:20:18-EST
From: Arun <Welch%osu-20@ohio-state.arpa>
Subject: Re: mailing address
To: Christopher.Hoover@SPICE.CS.CMU.EDU
Cc: Rick.Busdiecker@cs.cmu.edu, CL-Windows@Sail.Stanford.Edu, Gripe@cs.cmu.edu
In-Reply-To: Message from "Christopher.Hoover@SPICE.CS.CMU.EDU" of Thu 28 Jan 88 01:07:28-EST
I've had
Kimbrough%dsg%ti-csl@relay.cs.net
work fine for me. We sit behind csnet-relay, but I don't think that will make
a difference.
What is Lisp Pointers?
...arun
-------
∂27-Jan-88 2258 CL-Windows-mailer Re: mailing address
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Jan 88 22:58:29 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA03741; Wed, 27 Jan 88 22:58:48 PST
Received: By SPAR.SLB.COM (from hobbes.SPAR.SLB.COM)
id AA19626; Wed, 27 Jan 88 22:57:15 PST
Received: By hobbes.SPAR.SLB.COM (from localhost)
id AA00373; Wed, 27 Jan 88 22:57:11 PST
Message-Id: <8801280657.AA00373@hobbes.SPAR.SLB.COM>
To: CL-Windows@Sail.Stanford.Edu
Subject: Re: mailing address
In-Reply-To: Your message of Thu, 28 Jan 88 00:28:53 -0500.
<1867.570346133@SPICE.CS.CMU.EDU>
Date: Wed, 27 Jan 88 22:57:09 -0800
From: malcolm@SPAR.SLB.COM
Sorry to bother the whole net about this......but can somebody send me
a copy of the CLX Hello World example? I thought I had put aside a copy
when it first came over the net but now I can't find it.....argh.
Mucho thanks.
Malcolm Slaney
Schlumberger Palo Alto Research
malcolm@spar.slb.com
∂28-Jan-88 1240 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:40:31 PST
Date: Thu 28 Jan 88 14:41:44-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: Question about CLX and Kyoto Common Lisp
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12370277122.8.LRC.OPPENHEIM@R20.UTEXAS.EDU>
We are interested in using X windows in order to port applications
written in CLX to UNIX-based workstations. We want to use a
Kyoto Common Lisp compiler on the workstation. Have you, or do you
know of anyone, who has done something similar? I'd like to know
what kind of problems are involved in compiling CLX applications using
Kyoto CL.
Please respond directly to me, since I'm not yet on the mailing list.
Thanks very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
Linguistics Research Center
University of Texas, Austin
-------
∂28-Jan-88 1956 CL-Windows-mailer Lisp Pointers
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 19:56:08 PST
Received: from SPICE.CS.CMU.EDU by SPICE.CS.CMU.EDU; 28 Jan 88 22:56:52 EST
To: Arun <Welch%osu-20@ohio-state.arpa>
Cc: cl-windows@sail.stanford.edu
Subject: Lisp Pointers
In-reply-to: Your message of Thu, 28 Jan 88 01:20:18 -0500.
<8801280620.AA08460@tut.cis.ohio-state.edu>
Date: Thu, 28 Jan 88 22:56:45 EST
Message-ID: <9749.570427005@SPICE.CS.CMU.EDU>
From: Christopher.Hoover@SPICE.CS.CMU.EDU
``Lisp Pointers'' is a free newsletter which contains technical
articles and various columns on topics such as lisp implementations,
Scheme, and the XJ313 standardization.
To get on the mailing list, send physical mail to:
Lisp Pointers
Mary S. VanDeusen, editor
IBM Watson Research Center
P. O. Box 704
Yorktown Heights, NY 10598
Send her your physical address and state whether or not you object to
getting on various manufacturers' lispy mailing lists.
Volume 1, Number 4 contained an article by Kerry Kimbrough called
``Windows to the Future.'' The article is a quick introduction to
CLX and contains example code.
-- Christopher Hoover
(Christopher.Hoover@CS.CMU.EDU)
∂29-Jan-88 0914 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
Received: from MEAD.SCRC.Symbolics.COM ([128.81.41.234]) by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:14:18 PST
Received: from HAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131343; Fri 29-Jan-88 11:44:26 EST
Date: Fri, 29 Jan 88 11:45 EST
From: David Schatsky <schatsky@MEAD.SCRC.Symbolics.COM>
Subject: Question about CLX and Kyoto Common Lisp
To: LRC.OPPENHEIM@R20.UTEXAS.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12370277122.8.LRC.OPPENHEIM@R20.UTEXAS.EDU>
Message-ID: <19880129164549.4.SCHATSKY@HAN.SCRC.Symbolics.COM>
Date: Thu 28 Jan 88 14:41:44-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
We are interested in using X windows in order to port applications
written in CLX to UNIX-based workstations. We want to use a
Kyoto Common Lisp compiler on the workstation. Have you, or do you
know of anyone, who has done something similar? I'd like to know
what kind of problems are involved in compiling CLX applications using
Kyoto CL.
Please respond directly to me, since I'm not yet on the mailing list.
Thanks very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
Linguistics Research Center
University of Texas, Austin
-------
Would people include me in their responses? Thanks.
David Schatsky
Symbolics International Sales
∂29-Jan-88 1332 CL-Windows-mailer CLX resource extensions
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jan 88 13:32:02 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa08908; 29 Jan 88 14:45 EST
Received: from csc.ti.com by RELAY.CS.NET id aj06767; 29 Jan 88 14:30 EST
Received: from SI by tilde id AA03110; Fri, 29 Jan 88 12:39:28 CST
Message-Id: <2779468677-11407459@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 29 Jan 88 12:37:57 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX resource extensions
The C language resource functions operate on name and class lists that
go from least-specfic to most-specific. For example:
(application frame menu item1)
In the lisp world, its more convenient and space efficient to go the
other way:
(item1 menu frame application)
When done this way, all items in menu share the same sub-list.
For example, with the C ordering, you've got to do:
(setq item-name-list (append parents-item-name-list (list item-name)))
But with a reversed ordering, its simply:
(setq item-name-list (cons item-name parents-item-name-list))
It bothers me that every item needs to copy its parent's list,
instead of using a single cons. Should CLX resources have a reverse
ordering relative to the C world? Am I still living in the dark ages of
expensive memory? More to the point, are the savings inherent in
reversing the ordering worth the possible confusion?
Please Comment
LaMott
∂01-Feb-88 1425 CL-Windows-mailer Please add me on the Distribution List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Feb 88 14:25:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 FEB 88 13:49:54 PST
Date: 1 Feb 88 13:48 PST
From: Tateno.pa@Xerox.COM
Subject: Please add me on the Distribution List
To: cl-windows@sail.stanford.edu
cc: Tateno.pa@Xerox.COM
Message-ID: <880201-134954-2288@Xerox>
I'm an engineer & Resident at Xerox Artificial Intelligence Systems from Fuji
Xerox in Japan. Would you please add me on the Distribution List?
and One Question...
Is it possible for me to get CLX?
//Masa
∂08-Feb-88 1715 CL-Windows-mailer CLX support for NOOP request?
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Feb 88 17:15:41 PST
Received: from suntoo.sun.com (suntoo-bb.sun.com) by Sun.COM (4.0/SMI-3.2)
id AA11660; Mon, 8 Feb 88 17:16:12 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA07172; Mon, 8 Feb 88 17:18:51 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA05012; Mon, 8 Feb 88 20:06:33 EST
Received: from frob.sun.com by eti.com (3.2/SMI-3.2)
id AA09129; Fri, 5 Feb 88 12:54:27 EST
Received: by frob.sun.com (3.2/SMI-3.2)
id AA00303; Fri, 5 Feb 88 12:54:57 EST
Date: Fri, 5 Feb 88 12:54:57 EST
From: sunpitt!eti!frob!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8802051754.AA00303@frob.sun.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: CLX support for NOOP request?
Is there any? Should there be?
Rick Busdiecker
Expert Technologies, Inc.
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂09-Feb-88 0821 CL-Windows-mailer Re: CLX support for NOOP request?
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Feb 88 08:21:15 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab08492; 9 Feb 88 11:21 EST
Received: from csc.ti.com by RELAY.CS.NET id ab29329; 9 Feb 88 11:18 EST
Received: from SI by tilde id AA19764; Tue, 9 Feb 88 09:17:11 CST
Message-Id: <2780406918-3713673@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 9 Feb 88 09:15:18 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: Rick Busdiecker <sunpitt!eti!frob!rick@SUN.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX support for NOOP request?
In-Reply-To: Msg of Fri, 5 Feb 88 12:54:57 EST from Rick Busdiecker <sunpitt!eti!frob!rick@sun.com>
Date: Fri, 5 Feb 88 12:54:57 EST
From: Rick Busdiecker <sunpitt!eti!frob!rick@sun.com>
Subject: CLX support for NOOP request?
Is there any? Should there be?
The following is at the bottom of the CLX/requests.l file:
#+comment ;; This is a protocol request, but its not very interesting...
(defun no-operation (display)
(declare (type display display))
(with-buffer-request (display *x-nooperation*)))
I thought the purpose of the NOOP request was for padding out requests
to a multiple of 64 bits on machines with 64 bit word sizes (i.e. Cray).
I see no need for a user of CLX to send NOOPs, however an implementation
of CLX on a Cray might send NOOP requests.
I suspect the only reason the C Xlib code includes XNoOp is for server
testing. If you're doing server testing with CLX, perhaps the
no-operation function (above) should be a part of your test code, rather
than in CLX. You will probably want to use the CLX macros anyway, to
test server error checking by generating incorrect requests.
∂12-Feb-88 1338 CL-Windows-mailer Re: CLX event queue
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Feb 88 13:38:35 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj29782; 12 Feb 88 15:42 EST
Received: from csc.ti.com by RELAY.CS.NET id aj06849; 12 Feb 88 15:35 EST
Received: from dsg by tilde id AA12303; Fri, 12 Feb 88 13:56:06 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 12 Feb 88 13:57:30 CST
Message-Id: <2780682848-3857788@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Fri, 12 Feb 88 13:54:08 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX event queue
In-Reply-To: Msg of Fri, 12 Feb 88 13:06:31 CST from LaMott Oren <Oren@Home.TI>
> 2. When discard-p is true, remove the event from the queue BEFORE
> processing the event. This makes the throw behavior "discard"
> when discard-p else "keep". (I favor this option)
This approach would create a problem in CLUE. Since CLUE:PROCESS-NEXT-
EVENT hard-wires discard-p true, the CLUE programmer is unable to elect
"throw but keep". Perhaps CLUE should change to allow the caller of
CLUE:PROCESS-NEXT-EVENT to define discard-p. But this still doesn't
change the problem: a programmer still needs the ability to keep or
discard when throwing, regardless of the default policy of the
surrounding process-event.
> 1. Provide a discard-current-event function.
I favor this approach. How about "pop-event"?
∂12-Feb-88 1403 CL-Windows-mailer CLX event queue
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Feb 88 14:03:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae29782; 12 Feb 88 15:41 EST
Received: from csc.ti.com by RELAY.CS.NET id ae06849; 12 Feb 88 15:34 EST
Received: from SI by tilde id AA11402; Fri, 12 Feb 88 13:08:02 CST
Message-Id: <2780679991-5111499@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 12 Feb 88 13:06:31 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX event queue
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
∂19-Feb-88 1211 CL-Windows-mailer CLX documentation
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 12:11:14 PST
Date: Fri 19 Feb 88 11:33:10-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: CLX documentation
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12376009962.40.LRC.OPPENHEIM@R20.UTEXAS.EDU>
Can someone tell me where I can get some documentation on CLX? Thanks
very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
-------
∂24-Feb-88 1651 CL-Windows-mailer How to handle timeout of 0 in Lucid's Lisp
Received: from csv.rpi.edu (cs.rpi.edu) by SAIL.Stanford.EDU with TCP; 24 Feb 88 16:50:36 PST
Received: by csv.rpi.edu (5.54/1.14)
id AA15909; Wed, 24 Feb 88 19:54:36 EST
Date: Wed, 24 Feb 88 19:54:36 EST
From: harrisr@csv.rpi.edu (Richard Harris)
Message-Id: <8802250054.AA15909@csv.rpi.edu>
To: cl-windows@sail.stanford.edu
Subject: How to handle timeout of 0 in Lucid's Lisp
Rick Busdiecker asks:
>Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
>work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
It is easy to handle timeout=0 in Lucid with listen.
I also changed xlib:event-loop, since it handled timeouts of 0
differently than other (non-nil) timeouts. I needed both of these
changes in order to make an event handler loop which runs a function
before every time xlib:event-loop needs to wait.
Rick Harris
;From dependent
#-(or symbolics-3600 explorer)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
(type array-index start end)
(type (or null number) timeout))
(declare-buffun)
(let ((stream (display-input-stream display)))
(declare (type stream stream))
(if (and (eql timeout 0) (null (listen stream)))
:timeout
(do* ((i start (index+ i 1))
(c nil))
((index>= i end) nil)
(declare (type array-index i)
(type (or null card8) c))
(setq c (read-byte stream nil nil))
(if c
(setf (aref vector i) c)
(return t))))))
;From input
;The only change here is that what used to be:
; ((or ,result
; (and (endp ,events) ,timeout (zerop ,timeout)))
;is now:
; (,result
(defmacro event-loop ((display event timeout peek-p discard-p force-output-p) &body body)
;; Bind EVENT to the events for DISPLAY.
;; This is the "GUTS" of process-event and event-case.
(let ((previous (gensym))
(events (gensym))
(result (gensym))
(new (gensym)))
`(with-event-queue (,display)
(let ((,previous nil)
(,events (display-event-queue ,display)))
(when (boundp '*recursive-event-queue*)
(setq ,previous *recursive-event-queue*
,events (cdr *recursive-event-queue*)))
(do ((,result nil))
(,result
,result)
; Read events when queue empty
(unless ,events
,(when force-output-p
`(when ,force-output-p (display-force-output ,display)))
(when (wait-for-event ,display ,timeout)
(return nil)) ;; return when timeout exceeded
;; Look at the new events just read. The value of Previous is still good.
(setq ,events (display-new-events ,display)))
; Keep the new-event list updated
(with-event-queue-internal (,display)
;; When event is new, Pop the new-event list
(let ((,new (display-new-events ,display)))
(when (eq ,events ,new)
(setf (display-new-events ,display) (cdr ,new)))))
; Execute the body
(let ((,event (car ,events))
(*recursive-event-queue* ,events))
(setq ,result (progn ,@body))
; Delete entry when ,result was NIL
(if (if ,result
(not ,peek-p)
,discard-p)
(progn ;Delete event
(if ,previous ; When Event in middle of queue,
(setf (cdr ,previous) (cdr ,events)) ;; Destructively splice it out.
(pop (display-event-queue ,display)))
(deallocate-event ,event))
(setq ,previous ,events))) ; Don't delete event - update previous
(pop ,events)
)))))
∂16-Mar-88 1206 CL-Windows-mailer Re: CLX event queue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:00:42 PST
Received: by ti.com id AA09679; Wed, 16 Mar 88 08:59:30 CST
Received: from SI by tilde id AA05886; Wed, 16 Mar 88 08:57:54 CST
Message-Id: <2783516351-5096244@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 16 Mar 88 08:59:11 CST
From: LaMott Oren <Oren@Home.csc.ti.com>
To: John Irwin <franz!sparky!jdi@ucbarpa.berkeley.edu>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Msg of Tue, 15 Mar 88 15:19:24 PST from John Irwin <franz!sparky!jdi@ucbarpa.berkeley.edu>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case?
No. All clue has ever needed was option #2. Kerry Kimbrough thought it
was required, but I talked him out of it.
I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
Did you see my posting to bug-clx@zermatt.lcs.mit.edu with the
implementation for option #2? If you have that patch,
discard-current-event should be as simple as:
(defun discard-current-event ()
;; Re-use the storage allocated to the current event
(deallocate-event (cadr *recursive-event-queue*))
;; Splice current event out of the event queue
(setf (cdr *recursive-event-queue*) (cddr *recursive-event-queue*)))
It seems to me that discard-current-event is dangerous because its too
easy to lose events and you can always find a work-around for not having
it. In addition, the if you call discard-current-event then fall
through the normal event deletion code, the event will be deallocated
twice, which will REALLY wreck havoc [perhaps the deallocate-event call
should be removed from discard-current-event?]. The only place I can
think of where discard-current-event would NOT be dangerous is when used
inside event-case (or process-event) with the :peek-p parameter non-nil
and :discard-p nil.
∂16-Mar-88 1222 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1230 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1346 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1349 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1459 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1729 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1459 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1729 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂06-Apr-88 1627 CL-Windows-mailer CLX
Received: from nrl-aic.arpa by SAIL.Stanford.EDU with TCP; 6 Apr 88 16:27:31 PDT
Return-Path: <schultz@nrl-aic.arpa>
Received: Wed, 6 Apr 88 18:23:38 EST by nrl-aic.arpa id AA10672
Date: Wed, 6 Apr 88 18:23:38 EST
From: Alan Schultz <schultz@nrl-aic.arpa>
Message-Id: <8804062323.AA10672@nrl-aic.arpa>
To: cl-windows@sail.stanford.edu
Subject: CLX
------------------------------------------------------------
PLEASE SEND REPLIES DIRECTLY TO schultz@nrl-aic.arpa !!!!!
------------------------------------------------------------
We have a Sun 3/160C running SunOS 3.4. I have just finished installing
X.V11R2 and everything appears to be working fine.
Our lisp is Sun Common Lisp 2.1.1 (Lucid). The problem is in getting
CLX to work. I did the following:
1) Changed all files ending in .l to .lisp
2) cc -c socket.c ;;; to create socket.c as needed on lucid systems
3) uudecoded ms-patch.uu to create make-sequence-patch.lbin
which is automatically loaded by the "#+lucid" directive.
4) Changed the line in "defsystem.lisp" from
.... '("-lc") ...
to
... '("-lresolv" "-lc") ...
after noting that we do have the resolv library. This also was correct
under V11R1 (CLX worked for us then).
5) Started Lisp (and yes, the X server was already started!)
6) > (load "defsystem")
7) > (compile-clx) ;; this worked fine, no unusual problems
8) > (disksave "clx-lisp") ;; to create an image
9) > (quit) ;; quit lisp
Now, when I type clx-lisp, I get my new lisp image with CLX, but I can't
get open-display to work in any way. I tried the programs in CLX/test,
CLX/debug, and I simply typed at the top level...
(setq display (open-display "aic-sun8")), and in all cases, I got back the
message...
>> Failed to connect to server: aic-sun8 0
OPEN-X-STREAM
Required arg 0 (Host): "aic-sun8"
Required arg 1 (Display): 0
Required arg 2 (Protocol): nil
I tried aic-sun8 (which is what 'hostname' returns on my machine, and
works otherwise in X.V11R2), and I tried unix. Note that CLX only wants
the host and an optional display that defaults to 0 as separate arguments
for open-display. "aic-sun8:0.0" is INcorrect under CLX.
Please help. We have an important project on which I must move quickly that
depends on using CLX. I would like to here from anyone that has CLX
working on a Sun.
Alan C. Schultz
Code 5510
Navy Center for Applied Research in Artificial Intelligence (NCAR A I)
Naval Research Laboratory
Washington, D.C. 20375-5000
ARPA: schultz@nrl-aic.arpa
(202) 767-2877
∂14-Apr-88 1224 CL-Windows-mailer CLX Package Name
Received: from CHILES.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 88 12:23:58 PDT
Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 14 Apr 88 15:23:53 EDT
To: cl-windows@sail.stanford.edu
Subject: CLX Package Name
Date: Thu, 14 Apr 88 15:23:32 EDT
From: Bill.Chiles@WB1.CS.CMU.EDU
I'm just starting to play with CLX, and I haven't been closely reading this
mailing list. I hope I won't open a sour subject with my query.
Is there a good reason the CLX package name is "XLIB" instead of "CLX"? Can it
be renamed with "XLIB" as a nickname, or can "CLX" be added as a nickname? If
the authors are opposed to changing the name or adding a nickname, does anyone
see any harm in locally adding "CLX" as a nickname and using it in code?
I don't mean to be petty about names, but if there's no cost, I'd feel better
using "CLX".
Bill
∂14-Apr-88 1529 CL-Windows-mailer CLX Package Name
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 88 15:29:07 PDT
Received: from KILLINGTON.LCS.MIT.EDU by EXPO.LCS.MIT.EDU; Thu, 14 Apr 88 18:29:24 EDT
Date: Thu, 14 Apr 88 18:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX Package Name
To: Bill.Chiles@WB1.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Apr 88 15:23 EDT from Bill.Chiles@WB1.CS.CMU.EDU
Message-Id: <880414182948.7.RWS@KILLINGTON.LCS.MIT.EDU>
Here's some old mail on the subject. I guess I don't really see the point
in adding CLX as a nickname. (Since the designers named the package XLIB,
why would you feel better using CLX? For the same reason the designers
named it X Window System, but people feel better using X-Windows? :-)
Date: Fri, 1 May 87 10:23 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Date: Thu, 30 Apr 87 19:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
8. I suggest using another package name, rather than "XLIB" (how about
"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
already confounds discussions of the many bits and pieces of X (e.g.
"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
language binding, this is just a matter of finding a name that says what
is it is and doesn't say what it isn't.
I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
isn't that much CL about the interface that it couldn't mostly be used in other
dialects). Just "X" is too short. Any other suggestions? Any other objections
to "XLIB"?
I think "XLIB" is a good choice. It's true that there could be confusion
between the Lisp XLIB and the C XLib. But I think this is outweighed by the
benefits of making it clear that both of these things are instances of the
same level of abstraction and modularity. In other words, there really IS a
Lisp one and a C one, and the naming should reflect that reality in order to
make clear the relationship between the two.
∂25-Apr-88 1108 CL-Windows-mailer CLUE and with-gcontext
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 Apr 88 11:08:38 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA20910; Mon, 25 Apr 88 11:08:39 PDT
Received: By SPAR.SLB.COM (from hobbes.SPAR.SLB.COM)
id AA25151; Mon, 25 Apr 88 10:40:22 PDT
Received: By hobbes.SPAR.SLB.COM (from localhost)
id AA02400; Mon, 25 Apr 88 10:40:17 PDT
Message-Id: <8804251740.AA02400@hobbes.SPAR.SLB.COM>
To: cl-windows@sail.stanford.edu
Subject: CLUE and with-gcontext
Date: Mon, 25 Apr 88 10:40:16 -0700
From: malcolm@spar-20.spar.slb.com
Two questions.....
First, who is working on an object oriented interface for the X window
system? Is this the same as the CLUE effort? Schlumberger (like many
organizations, I suspect) is trying to settle on a window system standard
and an object oriented approach (ala Symbolics) sounds like the best
approach to me. Can anybody fill me in on the progress?
Second, I had a lot of problems when I tried to change a gcontext while
inside the body of a with-gcontext. Perhaps the documentation could
be modified to indicate that it isn't possible to change the gcontext
within a with-gcontext.
Thanks.
Malcolm
∂26-Apr-88 0930 CL-Windows-mailer CLUE code available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Apr 88 09:30:01 PDT
Received: by ti.com id AA04267; Tue, 26 Apr 88 11:28:51 CDT
Received: from SI by tilde id AA13029; Tue, 26 Apr 88 11:24:40 CDT
Message-Id: <2787063763-8703946@SI>
Sender: OREN@SI.csc.ti.com
Date: Tue, 26 Apr 88 11:22:43 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: cl-windows@sail.stanford.edu
Cc: xpert@ATHENA.MIT.EDU
Subject: CLUE code available
A portable implementation of the Common Lisp User interface Environment (CLUE)
is now available in the public domain. Anyone interested may receive source
code and documentation via anonymous ftp from CSC.TI.COM, (internet address
10.7.0.46) in pub/clue.tar.Z A copy will soon be available from
EXPO.LCS.MIT.EDU.
This implementation of CLUE (Version 1.13) may be installed without change in TI
Explorer and Symbolics environments. Other configurations have not yet been
tested. Bug reports and fixes are welcome and should be addressed to one of the
following addresses. The standard X bug report format is nice and is preferred.
clue-bugs@dsg.csc.ti.com
(...im4u!ti-csl!dsg!clue-bugs).
We encourage comments from anyone interested in Lisp user interface programming.
General comments and CLUE issue discussion should be addressed to
cl-windows@sail.stanford.edu or to clue-review@dsg.csc.ti.com.
CLUE is a portable system for user interface programming in Common Lisp. CLUE,
which is based on the X Window System and the Common Lisp Object System (CLOS),
extends the CLX interface to provide an architectural model for the construction
of interactive Lisp applications. Modeled on the Xtk toolkit library, CLUE
could be described as a translation of the Xtk "intrinsics" into the domain of
Common Lisp and CLOS.
∂26-Apr-88 1029 CL-Windows-mailer CLUE code available
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by SAIL.Stanford.EDU with TCP; 26 Apr 88 10:29:26 PDT
Received: from RUSSIAN.SPA.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185351; Tue 26-Apr-88 13:28:51 EDT
Received: from SIERRA-NEVADA.SPA.Symbolics.COM by RUSSIAN.SPA.Symbolics.COM via CHAOS with CHAOS-MAIL id 60936; Tue 26-Apr-88 10:26:46 PDT
Date: Tue, 26 Apr 88 10:27 PDT
From: jan cornish <cornish@RUSSIAN.SPA.Symbolics.COM>
Subject: CLUE code available
To: Oren@Home.csc.ti.com
cc: cl-windows@sail.stanford.edu, xpert@ATHENA.MIT.EDU
In-Reply-To: <2787063763-8703946@SI>
Message-ID: <19880426172704.2.CORNISH@SIERRA-NEVADA.SPA.Symbolics.COM>
Date: Tue, 26 Apr 88 11:22:43 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
A portable implementation of the Common Lisp User interface Environment (CLUE)
is now available in the public domain. Anyone interested may receive source
code and documentation via anonymous ftp from CSC.TI.COM, (internet address
10.7.0.46) in pub/clue.tar.Z A copy will soon be available from
EXPO.LCS.MIT.EDU.
This implementation of CLUE (Version 1.13) may be installed without change in TI
Explorer and Symbolics environments. Other configurations have not yet been
tested.
Could you please tell me whether this implementation of CLUE can be
installed on an Xerox 1186 ?
Thank you very much,
Jan Cornish
Symbolics Consulting Group
Bug reports and fixes are welcome and should be addressed to one of the
following addresses. The standard X bug report format is nice and is preferred.
clue-bugs@dsg.csc.ti.com
(...im4u!ti-csl!dsg!clue-bugs).
We encourage comments from anyone interested in Lisp user interface programming.
General comments and CLUE issue discussion should be addressed to
cl-windows@sail.stanford.edu or to clue-review@dsg.csc.ti.com.
CLUE is a portable system for user interface programming in Common Lisp. CLUE,
which is based on the X Window System and the Common Lisp Object System (CLOS),
extends the CLX interface to provide an architectural model for the construction
of interactive Lisp applications. Modeled on the Xtk toolkit library, CLUE
could be described as a translation of the Xtk "intrinsics" into the domain of
Common Lisp and CLOS.
∂26-Apr-88 1050 CL-Windows-mailer CLUE and with-gcontext
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 10:50:34 PDT
Received: by expo.lcs.mit.edu; Tue, 26 Apr 88 13:50:46 EDT
Date: Tue, 26 Apr 88 13:50 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: CLUE and with-gcontext
To: malcolm@spar-20.spar.slb.com, cl-windows@sail.stanford.edu
In-Reply-To: <8804251740.AA02400@hobbes.SPAR.SLB.COM>
Message-Id: <880426135059.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 25 Apr 88 10:40:16 -0700
From: malcolm@spar-20.spar.slb.com
Second, I had a lot of problems when I tried to change a gcontext while
inside the body of a with-gcontext. Perhaps the documentation could
be modified to indicate that it isn't possible to change the gcontext
within a with-gcontext.
It's supposed to be possible. Perhaps you could send sample code, and
an indication of what you expect as correct behavior, to
bug-clx@zermatt.lcs.mit.edu.
∂26-Apr-88 1140 CL-Windows-mailer CLX spec
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 11:39:47 PDT
Received: by expo.lcs.mit.edu; Tue, 26 Apr 88 14:40:16 EDT
Date: Tue, 26 Apr 88 14:40 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: CLX spec
To: cl-windows@sail.stanford.edu, xtensions@athena.mit.edu
Cc: bug-clx@zermatt.lcs.mit.edu
Message-Id: <880426144024.1.RWS@KILLINGTON.LCS.MIT.EDU>
The MIT X Consortium is interested in hiring (yes, real money) someone
to write a definitive specification of the CLX interface; something
substantially more than the current "documentation", but perhaps less
voluminous than the C Xlib manual. If you are interested, contact me:
Bob Scheifler
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
rws@zermatt.lcs.mit.edu
∂26-Apr-88 1631 CL-Windows-mailer Re: CLUE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Apr 88 16:30:07 PDT
Received: by ti.com id AA06640; Tue, 26 Apr 88 18:28:39 CDT
Received: from dsg by tilde id AA21619; Tue, 26 Apr 88 18:16:36 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 26 Apr 88 18:18:27 CDT
Message-Id: <2787088469-339934@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 26 Apr 88 18:14:29 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: malcolm@spar-20.spar.slb.com
Subject: Re: CLUE
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Msg of Mon, 25 Apr 88 10:40:16 -0700 from malcolm@spar-20.spar.slb.com
Who is working on an object oriented interface for the X window
system? Is this the same as the CLUE effort? Schlumberger (like many
organizations, I suspect) is trying to settle on a window system standard
and an object oriented approach (ala Symbolics) sounds like the best
approach to me. Can anybody fill me in on the progress?
Malcolm, I can tell you some more about CLUE. To my knowledge, CLUE is
the only attempt to integrate OOP a la the proposed standard CLOS with X
at the *toolkit* level. While the definition of this "level" is rather
vague, you can contrast CLUE with work done by Rick Busdiecker at CMU
(Rick.Busdiecker@cs.cmu.edu), which simply makes CLOS classes out of X
windows/drawables/pixmaps. In the non-Lisp world, there are several OOP
interfaces to X: InterViews (C++), X-Toolkit (roll-yer-own-in-C), Andrew
Toolkit (yet another roll-yer-own-in-C). You can find out more about
CLUE by checking out the public source and documentation (see below).
Regarding window system standards, we leave the terra firma of facts and
tread the dark waters of speculation. My own opinion is that
standardization at the level of toolkit intrinsics is possible and
beneficial. By "intrinsics" I mean the fundamental model and
*policy-free* mechanisms by which any UI can be portably defined. By
"toolkit" I mean something at a higher level than the X protocol and
CLX; I also firmly believe that "toolkit" means OOP, which in turn means
CLOS. A standard of this sort would be beneficial because it would
greatly enhance the ability to deliver a sophisticated UI which is very
portable. It would stimulate, rather than constrain, the marketplace,
since vendors could compete on style, look'n'feel, features, etc. on a
greater number of delivery systems. Being policy-free is also the key
to "possible", since only then will such a standard achieve the
necessary consensus (and even then it will be a tough slog!).
But this is a tricky "in between" level we're shooting at. If you make
it too high-level -- say, try to standardize (pop-up-menu-choose
...) or to standardize the interface to window titles -- then you start
to wire in certain policies and/or reduce the number of possible
policies. The marketplace may create niches for higher-level UI policy
standards (OPEN LOOK, anyone?), but it isn't ready to adopt one to
the official exclusion of all others.
--------------
A portable implementation of the Common Lisp User interface Environment (CLUE)
is now available in the public domain. Anyone interested may receive source
code and documentation via anonymous ftp from CSC.TI.COM, (internet address
10.7.0.46) in pub/clue.tar.Z A copy will soon be available from
EXPO.LCS.MIT.EDU.
This implementation of CLUE (Version 1.13) may be installed without change in TI
Explorer and Symbolics environments. Other configurations have not yet been
tested. Bug reports and fixes are welcome and should be addressed to one of the
following addresses. The standard X bug report format is nice and is preferred.
clue-bugs@dsg.csc.ti.com
(...im4u!ti-csl!dsg!clue-bugs).
We encourage comments from anyone interested in Lisp user interface programming.
General comments and CLUE issue discussion should be addressed to
cl-windows@sail.stanford.edu or to clue-review@dsg.csc.ti.com.
CLUE is a portable system for user interface programming in Common Lisp. CLUE,
which is based on the X Window System and the Common Lisp Object System (CLOS),
extends the CLX interface to provide an architectural model for the construction
of interactive Lisp applications. Modeled on the Xtk toolkit library, CLUE
could be described as a translation of the Xtk "intrinsics" into the domain of
Common Lisp and CLOS.
∂27-Apr-88 0701 CL-Windows-mailer Re: CLUE code available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Apr 88 07:01:08 PDT
Received: by ti.com id AA10384; Wed, 27 Apr 88 08:58:36 CDT
Received: from SI by tilde id AA03355; Wed, 27 Apr 88 08:46:46 CDT
Message-Id: <2787140683-13325412@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 27 Apr 88 08:44:43 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: jan cornish <cornish@russian.spa.symbolics.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLUE code available
In-Reply-To: Msg of Tue, 26 Apr 88 10:27 PDT from jan cornish <cornish@russian.spa.symbolics.com>
Date: Tue, 26 Apr 88 10:27 PDT
From: jan cornish <cornish@russian.spa.symbolics.com>
Subject: CLUE code available
Date: Tue, 26 Apr 88 11:22:43 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
A portable implementation of the Common Lisp User interface Environment (CLUE)
is now available in the public domain. Anyone interested may receive source
code and documentation via anonymous ftp from CSC.TI.COM, (internet address
10.7.0.46) in pub/clue.tar.Z A copy will soon be available from
EXPO.LCS.MIT.EDU.
This implementation of CLUE (Version 1.13) may be installed without change in TI
Explorer and Symbolics environments. Other configurations have not yet been
tested.
Could you please tell me whether this implementation of CLUE can be
installed on an Xerox 1186 ?
CLUE is written in vanilla common-lisp and includes what I call
CLOS-KLUDGE, which is a hack to implement a limited subset of the
proposed CLOS specification (no multiple inheritance or meta classes).
It should run on anybody's common-lisp, but that's what I though about
CLX, and folks have found lots of nits in it ;-)
The answer to your question is YES, but be prepared to fix (and report
back to us) the problems you encounter.
∂27-Apr-88 0913 CL-Windows-mailer RE: CLUE code available
Received: from PLUTO.ARC.NASA.GOV by SAIL.Stanford.EDU with TCP; 27 Apr 88 09:10:41 PDT
Date: Wed 27 Apr 88 09:11:09-PDT
From: Will Taylor <TAYLOR@PLUTO.ARC.NASA.GOV>
To: cl-windows@sail.STANFORD.EDU
Subject: RE: CLUE code available
Does the CLUE code on CSC.TI.COM include necessary support for X-windows,
CLX & CLOS which I understand underlie CLUE? If not, where do I get those
codes?
- Will taylor@pluto.arc.nasa.gov
∂27-Apr-88 1029 CL-Windows-mailer
Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 27 Apr 88 10:28:43 PDT
Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ;
Wed, 27 Apr 88 10:28:39 PDT
Date: Wed, 27 Apr 88 10:28:39 PDT
From: POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Message-Id: <880427102839.20c00216@NMFECC.ARPA>
To: CL-windows@sail.stanford.edu
Subject: X windows capabilities question
Date: Wed, 27-APR-1988 09:50 MST
X-VMS-Mail-To: ARPA%"CL-windows%sail.stanford.edu@nmfecc.arpa"
Does X windows support color? How many bit planes can it support? Will
it run under AUX on the MAC?
pothiers%tuva.sainet@nmfecc.arpa
∂27-Apr-88 1046 CL-Windows-mailer X
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 10:46:17 PDT
Received: by expo.lcs.mit.edu; Wed, 27 Apr 88 13:46:35 EDT
Date: Wed, 27 Apr 88 13:46 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: X
To: POTHIERS%TUVA.SAINET.MFENET@nmfecc.arpa, CL-windows@sail.stanford.edu
In-Reply-To: <880427102839.20c00216@NMFECC.ARPA>
Message-Id: <880427134642.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 27 Apr 88 10:28:39 PDT
From: POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Does X windows support color?
Yes.
How many bit planes can it support?
32
Will it run under AUX on the MAC?
Yes, but you can't get it yet. Also A/UX 1.0 doesn't
provide the support necessary for color. Maybe fixed
in next release.
∂27-Apr-88 1515 CL-Windows-mailer Re: X windows capabilities question
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Apr 88 15:14:53 PDT
Received: by ti.com id AA12885; Wed, 27 Apr 88 17:13:05 CDT
Received: from SI by tilde id AA11314; Wed, 27 Apr 88 15:41:17 CDT
Message-Id: <2787165548-14819282@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 27 Apr 88 15:39:08 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: POTHIERS%TUVA.SAINET.MFENET@nmfecc.arpa
Cc: CL-windows@sail.stanford.edu
Subject: Re: X windows capabilities question
In-Reply-To: Msg of Wed, 27 Apr 88 10:28:39 PDT from POTHIERS%TUVA.SAINET.MFENET@nmfecc.arpa
Date: Wed, 27 Apr 88 10:28:39 PDT
From: POTHIERS%TUVA.SAINET.MFENET@nmfecc.arpa
Does X windows support color?
Yes.
How many bit planes can it support?
1, 4, 8, 16, 24 or 32.
Will it run under AUX on the MAC?
Yes. I've seen a MacII/AUX run X11, but don't know where it came from.
Its not in the XV11R2 distribution from MIT. Check with Apple.
∂27-Apr-88 1518 CL-Windows-mailer RE: CLUE code available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Apr 88 15:18:41 PDT
Received: by ti.com id AA12858; Wed, 27 Apr 88 17:12:28 CDT
Received: from SI by tilde id AA10452; Wed, 27 Apr 88 14:54:16 CDT
Message-Id: <2787162735-14650353@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 27 Apr 88 14:52:15 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: Will Taylor <TAYLOR@pluto.arc.nasa.gov>
Cc: cl-windows@sail.stanford.edu
Subject: RE: CLUE code available
In-Reply-To: Msg of Wed 27 Apr 88 09:11:09-PDT from Will Taylor <TAYLOR@pluto.arc.nasa.gov>
Does the CLUE code on CSC.TI.COM include necessary support for X-windows,
CLX & CLOS which I understand underlie CLUE? If not, where do I get those
codes?
You'll need CLX from the MIT X version 11 release 2 distribution,
including fix number 11 from xstuff@expo.lcs.mit.edu.
CLUE includes a primitive CLOS subset.
∂29-Apr-88 1913 CL-Windows-mailer Gnu indent hook for (CLX:event-case)
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Apr 88 19:13:08 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
id AA09613; Fri, 29 Apr 88 19:12:58 PDT
Received: from sparky by franz (5.5/3.14)
id AA12906; Fri, 29 Apr 88 18:32:10 PDT
Received: by sparky (4.0/3.14)
id AA09359; Fri, 29 Apr 88 18:25:54 PDT
Return-Path: <sparky!jdi>
Message-Id: <8804300125.AA09359@sparky>
To: cl-windows@sail.stanford.edu
Subject: Gnu indent hook for (CLX:event-case)
Date: Fri, 29 Apr 88 18:25:53 PDT
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Also known as "more than 30 chars per event-case body."
------- Forwarded Message
From: akbar!layer (Kevin Layer)
Date: Fri, 29 Apr 88 16:26:56 -0800
To: John Irwin <jdi>
cc: harry, jkf
Subject: Re: emacs indenting
Put this in .emacs
(put 'event-case
'common-lisp-indent-hook
'(4 &rest (&whole 2 (&whole 4 &rest 1) &body))
)
and you get this indentation:
(defun foo ()
(event-case (x-display :discard-p t)
(:button-release ()
t)
(:motion-notify (x y)
(if* vertical
then x
else y)
(xlib:motion-events win)
nil)
(otherwise ()
nil)))
------- End of Forwarded Message
∂02-May-88 0730 CL-Windows-mailer Re: Gnu indent hook for (CLX:event-case)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 May 88 07:30:37 PDT
Received: by ti.com id AA15161; Mon, 2 May 88 09:29:27 CDT
Received: from SI by tilde id AA19681; Mon, 2 May 88 09:23:05 CDT
Message-Id: <2787574856-14294519@SI>
Sender: OREN@SI.csc.ti.com
Date: Mon, 2 May 88 09:20:56 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Cc: bug-clx@zermatt.lcs.mit.edu
Subject: Re: Gnu indent hook for (CLX:event-case)
In-Reply-To: Msg of Fri, 29 Apr 88 18:25:53 PDT from John Irwin <franz!sparky!jdi@UCBARPA.BERKELEY.EDU>
Date: Fri, 29 Apr 88 18:25:53 PDT
From: John Irwin <franz!sparky!jdi@UCBARPA.BERKELEY.EDU>
Subject: Gnu indent hook for (CLX:event-case)
Also known as "more than 30 chars per event-case body."
This does the same for TI Explorer Zmacs:
#+explorer
(zwei:define-indentation event-case (1 1))
(This should go at the end of the CLX/dependent.l file)
∂10-May-88 1444 CL-Windows-mailer X Client Sofware for Symbolics
Received: from PLUTO.ARC.NASA.GOV by SAIL.Stanford.EDU with TCP; 10 May 88 14:43:59 PDT
Date: Tue 10 May 88 14:44:10-PDT
From: Will Taylor <TAYLOR@PLUTO.ARC.NASA.GOV>
To: cl-windows@sail.STANFORD.EDU
Subject: X Client Sofware for Symbolics
My understanding is that the CLUE/CLX software provides client
support for X windows on the Symbolics, but not server support.
Is software available for the Symbolics which provides X server
support, so that I can write window applications on the Symbolics and
display the results on the Symbolics, using CLUE/CLX?
If not, then am I left with having a Symbolics X client, for which I
must find an X server, e.g. a Sun, to which I can network?
- Will Taylor taylor@pluto.arc.nasa.gov
∂18-May-88 1401 CL-Windows-mailer Some questions
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 May 88 14:01:26 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA27123; Wed, 18 May 88 14:01:26 PDT
Date: Wed, 18 May 88 14:01:26 PDT
Message-Id: <8805182101.AA27123@decwrl.dec.com>
From: lowry%aitg.DEC@decwrl.dec.com (David Lowry, VAX LISP 291-8070)
To: cl-windows@sail.stanford.edu, LOWRY@decwrl.dec.com
Subject: Some questions
While reading through Version 4 of the CLX spec, I came up with the
following questions:
1. Why does DRAW-LINE take a relative-p argument? Does it mean
the X2 and Y2 points are drawn relative to the first two if true?
2. There are CIRCULATE-WINDOW-UP and CIRCULATE-WINDOW-DOWN functions,
but the C Xlib has XCirculateSubwindowsUp, XCirculateSubwindowsDown,
XRaiseWindow and XLowerWindow. They don't seem to map in any way.
Is this an oversight or how is it supposed to work?
3. The type DRAW-DIRECTION (a font hint) only has :left-to-right and
:right-to-left. Shouldn't it have :bottom-to-top and :top-to-bottom
also?
4. The function that takes a display and returns a list of screens,
why is it called DISPLAY-ROOTS? Shouldn't it be called DISPLAY-SCREENS?
Also, in the HELLO-WORLD example shipped with X11R2 they use
(display-default-screen <display>) to get the screen, but it
sounds like that function should return the screen number (usually
0), not a screen structure. The C Xlib follows this convention.
Thanks,
David Lowry
∂18-May-88 1434 CL-Windows-mailer Some questions
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 14:34:20 PDT
Received: by expo.lcs.mit.edu; Wed, 18 May 88 17:35:10 EDT
Date: Wed, 18 May 88 17:34 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: Some questions
To: lowry%aitg.DEC@decwrl.dec.com, cl-windows@sail.stanford.edu
In-Reply-To: <8805182101.AA27123@decwrl.dec.com>
Message-Id: <19880518213427.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 18 May 88 14:01:26 PDT
From: lowry%aitg.DEC@decwrl.dec.com (David Lowry, VAX LISP 291-8070)
1. Why does DRAW-LINE take a relative-p argument?
For consistency with DRAW-LINES and DRAW-POINTS.
Does it mean
the X2 and Y2 points are drawn relative to the first two if true?
Yes.
2. There are CIRCULATE-WINDOW-UP and CIRCULATE-WINDOW-DOWN functions,
but the C Xlib has XCirculateSubwindowsUp, XCirculateSubwindowsDown,
XRaiseWindow and XLowerWindow. They don't seem to map in any way.
Is this an oversight or how is it supposed to work?
circulate-window-{up,down} is equivalent to XCirculateSubwindows{Up,Down}. The
CLX names mirror the names in the protocol document. The Xlib folks decided
the name was confusing, and changed it. To me, both names are confusing (e.g.,
the Xlib name sounds like more than one subwindow is moved). (The "window" in
CirculateWindow wasn't intended to denote the window that is the argument to
the request, but that's the way it is typically interpreted.)
3. The type DRAW-DIRECTION (a font hint) only has :left-to-right and
:right-to-left. Shouldn't it have :bottom-to-top and :top-to-bottom
also?
No, those directions don't exist in the (final) X protocol.
4. The function that takes a display and returns a list of screens,
why is it called DISPLAY-ROOTS? Shouldn't it be called DISPLAY-SCREENS?
Probably should have been, but is it worth changing?
Also, in the HELLO-WORLD example shipped with X11R2 they use
(display-default-screen <display>) to get the screen, but it
sounds like that function should return the screen number (usually
0), not a screen structure. The C Xlib follows this convention.
For the most part, CLX was not designed to mirror the C Xlib, it was designed
to mirror the X protocol in a reasonable way in CL. It isn't clear to me, for
example, that passing around screen numbers instead of objects is useful.
∂23-May-88 0335 CL-Windows-mailer enter-me
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 23 May 88 03:35:41 PDT
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA25617; Mon, 23 May 88 06:35:26 EDT
Received: by mcvax.cwi.nl; Mon, 23 May 88 12:28:54 +0200 (MET)
Received: by cernvax.uucp (1.2/Ultrix2.0-B)
id AA06329; Mon, 23 May 88 12:11:13 +0200
Received: by delphi.uucp (3.2/SMI-3.2)
id AA23529; Mon, 23 May 88 11:26:01 +0200
Date: Mon, 23 May 88 11:26:01 +0200
From: mcvax!delphi!sm@uunet.UU.NET (Silvia Mazzini)
Message-Id: <8805230926.AA23529@delphi.uucp>
To: cl-windows@sail.stanford.edu
Subject: enter-me
Please add the following name to the mailing list:
cl-windows%delphi.uucp@sun.com
Thank you.
∂07-Jun-88 2033 CL-Windows-mailer looking for CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 7 Jun 88 20:33:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab04644; 7 Jun 88 21:03 EDT
Received: from etl.jp by RELAY.CS.NET id ai09150; 7 Jun 88 20:55 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA12523; Tue, 7 Jun 88 15:41:03 JST
Date: Tue, 7 Jun 88 15:41:03 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Subject: looking for CLUE
I'm looking for CLUE for use with Kyoto Common Lisp or TI Explorer.
Glad to hear it is available, but I have no access for FTP.
Do I have any chance to get it another way?
Thanks in advance for any help.
Haruyuki Kawabe
--
Haruyuki Kawabe
Knowledge system, Nippon Unisys Ltd., Japan
kawabe%etl.jp@relay.cs.net
∂10-Jun-88 0935 CL-Windows-mailer clue
Received: from ATHENA (ATHENA.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jun 88 09:35:24 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19725; Fri, 10 Jun 88 12:34:15 EDT
Received: by JAREK.MIT.EDU (5.45/4.7) id AA10416; Fri, 10 Jun 88 12:33:52 EDT
Message-Id: <8806101633.AA10416@JAREK.MIT.EDU>
To: bug-clx@expo.lcs.mit.edu
Cc: cl-windows@sail.stanford.edu
Subject: clue
Date: Fri, 10 Jun 88 12:33:42 EDT
From: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>
Could somebody, please, explain to me why the implementation of CLUE from
TI redefines DRAWABLE, WINDOW and PIXMAP to be CLOS classes ?
It breaks the modularity of the CLX/CLOS/CLUE system (now when I got CLX to
work I have to start again), and what about the CLX interface definition
(and applications not using CLOS) ?
There must be some good reason, I just don't know it.
Thanks,
Roman
∂10-Jun-88 1331 CL-Windows-mailer Re: clue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Jun 88 13:31:05 PDT
Received: by ti.com id AA13483; Fri, 10 Jun 88 15:28:19 CDT
Received: from SI by tilde id AA12727; Fri, 10 Jun 88 15:19:45 CDT
Message-Id: <2790965837-16064257@SI>
Sender: OREN@SI.csc.ti.com
Date: Fri, 10 Jun 88 15:17:17 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: "Roman J. Budzianowski" <roman@athena.mit.edu>
Cc: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Subject: Re: clue
In-Reply-To: Msg of Fri, 10 Jun 88 12:33:42 EDT from Roman J. Budzianowski <roman@athena.mit.edu>
Date: Fri, 10 Jun 88 12:33:42 EDT
From: Roman J. Budzianowski <roman@athena.mit.edu>
Subject: clue
Could somebody, please, explain to me why the implementation of CLUE from
TI redefines DRAWABLE, WINDOW and PIXMAP to be CLOS classes ?
It breaks the modularity of the CLX/CLOS/CLUE system (now when I got CLX to
work I have to start again), and what about the CLX interface definition
(and applications not using CLOS) ?
There must be some good reason, I just don't know it.
Thanks,
Roman
I'm a firm believer in keeping things simple, unless there's a good
reason not to. CLUE was designed this way to keep things simple.
We decided that we wanted CLUE to be viewed as a layer "on top of" CLX.
I.E. We want CLUE users to freely use CLX functions. The cleanest way
to do this is to make CLUE contacts a subclass of window, so you can
pass contacts to any CLX function requiring a window (or drawable), and
any CLX function returning a window can return a CLUE contact.
Second, at the time CLUE was being designed, DRAWABLEs didn't have a
PLIST slot, so the only way to make the association between a window and
its contact was with a hash table. Making CLUE contacts CLX window
objects allowed us to utilize the CLX window-id to window object lookup
in the CLX event code. This eliminates a second lookup and extra
bookkeeping.
The price we pay for this is that you've got to re-compile CLX with
DRAWABLE, WINDOW and PIXMAP defined as CLOS classes, which doesn't seem
like a big deal to me. All the CLX accessor/setf's still work, so the
"CLX interface definition" isn't changed. It seems to me that making
DRAWABLEs etc. CLOS classes doesn't break "the modularity of the
CLX/CLOS/CLUE system", but enhances it.
I'm aware that this is a religious issue and that RWS in particular
dislikes this approach (though I've never really understood why). If
there's community agreement that our approach is wrong, CLUE can be
changed so contacts have a slot that points to their associated window.
That would require replacing "contact" with "(contact-window contact)"
in all our CLX calls, but that's not a big deal (just ugly ;-)
- LaMott
∂10-Jun-88 1515 CL-Windows-mailer Re: clue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Jun 88 15:15:52 PDT
Received: by ti.com id AA14093; Fri, 10 Jun 88 17:12:56 CDT
Received: from dsg by tilde id AA14618; Fri, 10 Jun 88 17:03:27 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 10 Jun 88 17:00:53 CDT
Message-Id: <2790971976-4498700@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 10 Jun 88 16:59:36 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: "Roman J. Budzianowski" <roman@ATHENA.MIT.EDU>
Cc: bug-clx@expo.lcs.mit.edu, cl-windows@SAIL.STANFORD.EDU
Subject: Re: clue
In-Reply-To: Msg of Fri, 10 Jun 88 12:33:42 EDT from "Roman J. Budzianowski" <roman@ATHENA.MIT.EDU>
> ... (and [what about] applications not using CLOS) ?
Just wanted to follow up on one this one question not already answered by
LaMott. CLUE comes with a portable CL implementation of a CLUE subset that is
sufficient for most CLUE programming. So, applications not using CLOS for lack
of an implementation can forge ahead. But what if you're adapting an application
that already uses Flavors or some other OOPS? For the short term, you can either
live with two OOPS or hack the CLOS subset to integrate it with your base OOPS.
For the long term (for which CLUE was designed), think hard about using standard
CLOS only.
∂12-Jun-88 1142 CL-Windows-mailer Re: clue
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jun 88 11:41:53 PDT
Received: by expo.lcs.mit.edu; Sun, 12 Jun 88 14:41:38 EDT
Date: Sun, 12 Jun 88 14:41 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: Re: clue
To: Oren%Home.csc.ti.com@relay.cs.net, roman@athena.mit.edu
Cc: clue-review%dsg.csc.ti.com@relay.cs.net, cl-windows@sail.stanford.edu
In-Reply-To: <2790965837-16064257@SI>
Message-Id: <19880612184123.6.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 10 Jun 88 15:17:17 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
I'm aware that this is a religious issue and that RWS in particular
dislikes this approach (though I've never really understood why).
For the record, here's what I recall saying on this subject:
Well, to a large extent I think this depends on what you think the next
level up is, and whether you think it is X-specific or more generic. I
happen to agree with those wanting a more generic interface. One such
interface is a stream, which would combine a window and a gcontext; it
isn't clear that the window or the gcontext is dominant, or that making
one of them the base object in a class implementation hierarchy is
beneficial.
Another argument is that we want this interface *today*, while we begin
the process of figuring out what the higher levels look like. There is
a conflict here between portability in the near term and generality in
the long term. The higher levels certainly want to use CLOS. If it
turns out that using CLOS within CLX itself turns out to be desirable,
then we can certainly make that change. What is desirable is if we
don't make any decisions in CLX that preclude such a change later. If
you see things, please point them out. People are certainly free to
implement the CLX interface using CLOS, and experiment with that
functionality to prove the desirability.
∂12-Jun-88 2101 CL-Windows-mailer please add me to the cl-windows mailing list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Jun 88 21:01:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac01017; 12 Jun 88 23:55 EDT
Received: from etl.jp by RELAY.CS.NET id ad19447; 12 Jun 88 23:49 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA14783; Mon, 13 Jun 88 11:38:44 JST
Date: Mon, 13 Jun 88 11:38:44 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Reply-To: kawabe%etl.jp@RELAY.CS.NET
Subject: please add me to the cl-windows mailing list
Please add me to the cl-windows mailing list.
but the address for sending those mails is not
kawabe%etl.jp@relay.cs.net
but
cl-windows%etl.jp@relay.cs.net
because I want to distribute them to the interested people in Japan.
(The reply address of this mail is kawabe%etl.jp@relay.cs.net)
Haruyuki Kawabe
Knowledge System
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂15-Jun-88 0254 CL-Windows-mailer CLX Interface Specification
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Jun 88 02:54:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07558; 15 Jun 88 5:53 EDT
Received: from etl.jp by RELAY.CS.NET id ac12255; 15 Jun 88 5:49 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA13864; Wed, 15 Jun 88 14:52:33 JST
Date: Wed, 15 Jun 88 14:52:33 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX Interface Specification
I'm looking for
Scheifler, Robert W., et al.
CLX Interface Specification
referenced by
Kimbrough, Kerry, and Oren, LaMott,
Common Lisp User Interface Environment
Version 0.8, February 15, 1988
I want a LaTeX file if possible.
Thanks in advance for any help.
Haruyuki Kawabe
Knowledge System
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂15-Jun-88 0519 CL-Windows-mailer CLX Interface Specification
Received: from EXPO.LCS.MIT.EDU ([18.30.0.212]) by SAIL.Stanford.EDU with TCP; 15 Jun 88 05:19:05 PDT
Received: by expo.lcs.mit.edu; Wed, 15 Jun 88 08:18:47 EDT
Date: Wed, 15 Jun 88 08:18 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: CLX Interface Specification
To: kawabe%etl.jp@relay.cs.net, cl-windows@sail.stanford.edu
In-Reply-To: The message of 15 Jun 88 01:52 EDT from Haruyuki Kawabe <kawabe@etl.jp>
Message-Id: <19880615121852.7.RWS@KILLINGTON.LCS.MIT.EDU>
The "spec" is the file lib/CLX/doc.l in the MIT V11R2 distribution.
It is a plain text file. A real document is (hopefully) under
construction, but I can't give you any more than that right now.
∂15-Jun-88 0816 CL-Windows-mailer Re: CLX Interface Specification
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Jun 88 08:16:11 PDT
Received: by ti.com id AA16592; Wed, 15 Jun 88 10:13:15 CDT
Received: from dsg by tilde id AA24592; Wed, 15 Jun 88 10:11:22 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 15 Jun 88 10:08:31 CDT
Message-Id: <2791379169-12448405@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 15 Jun 88 10:06:09 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Haruyuki Kawabe <kawabe@etl.jp>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX Interface Specification
In-Reply-To: Msg of Wed, 15 Jun 88 14:52:33 JST from Haruyuki Kawabe <kawabe@etl.jp>
If you have the X.V11R2 distribution, then look at .../lib/CLX/doc.l.
This is the latest version of the CLX interface spec, given in the form
of pseudo-Lisp code for deftype's, defmacro's, defun's, etc. It is
rather terse and presumes that the reader is familiar with the X.V11R2
Protocol Specification (see .../doc/protocol/*).
∂17-Jun-88 0031 CL-Windows-mailer please add me to the cl-windows mailing list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 17 Jun 88 00:31:13 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad07796; 17 Jun 88 2:59 EDT
Received: from etl.jp by RELAY.CS.NET id ag04822; 17 Jun 88 2:52 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA28682; Fri, 17 Jun 88 10:43:24 JST
Date: Fri, 17 Jun 88 10:43:24 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Subject: please add me to the cl-windows mailing list
Please add me to the cl-windows mailing list.
but the address for sending those mails is not
kawabe%etl.jp@relay.cs.net
but
cl-windows%etl.jp@relay.cs.net
because I want to distribute them to the interested people in Japan.
(The reply address of this mail is kawabe%etl.jp@relay.cs.net)
Haruyuki Kawabe
Knowledge System
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂17-Jun-88 1652 CL-Windows-mailer Mailing list
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 16:52:00 PDT
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Fri 17 Jun 88 16:25:19-PDT
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Fri, 17 Jun 88 15:29:37 PST
Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Fri, 17 Jun 88 16:29:21 pdt
Received: by hplabsz; Fri, 17 Jun 88 16:30:45 pdt
Date: Fri, 17 Jun 88 16:30:45 pdt
From: Vicki J. Parish <parish%hplabsz@hplabs.HP.COM>
Message-Id: <8806172330.AA08530@hplabsz.hpl.hp.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Mailing list
Please remove me from the cl-windows mailing list.
Thank you. -- Vicki Parish
∂18-Jun-88 1733 CL-Windows-mailer X11V2 on SUN with color monitors
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jun 88 17:33:29 PDT
Received: by labrea.stanford.edu; Sat, 18 Jun 88 17:32:17 PDT
Received: by ibuki.UUCP (5.52/4.7)
id AA13349; Thu, 16 Jun 88 11:44:18 PDT
Date: Thu, 16 Jun 88 11:44:18 PDT
From: ibuki!rww@labrea.stanford.edu (Richard Weyhrauch)
Message-Id: <8806161844.AA13349@ibuki.UUCP>
To: cl-windows@sail.stanford.edu
Subject: X11V2 on SUN with color monitors
We are having trouble bring up X11V2 on color SUN monitors. Does
anyone have experience with this?
Richard Weyhrauch
IBUKI
∂27-Jun-88 0835 CL-Windows-mailer Re: clue
Received: from postgres.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 27 Jun 88 08:35:02 PDT
Received: by postgres.Berkeley.EDU (5.57/1.26)
id AA05619; Mon, 27 Jun 88 08:34:24 PDT
Message-Id: <8806271534.AA05619@postgres.Berkeley.EDU>
From: David C. Martin <dcmartin%postgres.Berkeley.EDU@Berkeley.EDU>
Organization: University of California at Berkeley - Dept of EECS/CS Division
Email: dcmartin@postgres.Berkeley.EDU or {ihnp4,decvax}!ucbvax!dcmartin
Phone: 415/642-9585 (O)
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: "Roman J. Budzianowski" <roman@athena.mit.edu>, clue-review@dsg.csc.ti.com,
cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Fri, 10 Jun 88 15:17:17 CDT
<2790965837-16064257@SI>
Subject: Re: clue
Date: Mon, 27 Jun 88 08:34:22 PDT
Sender: dcmartin%postgres.Berkeley.EDU@Berkeley.EDU
I implemented something quite like CLUE for version 10 which works on top of
my version 10 CL interface called XCL. I found that I spent a good deal of
time mapping window id's to event objects, however, I also found that the
underlying libraries (XCL) ran considerably faster since no object-oriented
methodology was used in its implementation.
dcm
--------
Your message:
Date: Fri, 10 Jun 88 12:33:42 EDT
From: Roman J. Budzianowski <roman@athena.mit.edu>
Subject: clue
Could somebody, please, explain to me why the implementation of CLUE fro
m
TI redefines DRAWABLE, WINDOW and PIXMAP to be CLOS classes ?
It breaks the modularity of the CLX/CLOS/CLUE system (now when I got CLX
to
work I have to start again), and what about the CLX interface definition
(and applications not using CLOS) ?
There must be some good reason, I just don't know it.
Thanks,
Roman
I'm a firm believer in keeping things simple, unless there's a good
reason not to. CLUE was designed this way to keep things simple.
We decided that we wanted CLUE to be viewed as a layer "on top of" CLX.
I.E. We want CLUE users to freely use CLX functions. The cleanest way
to do this is to make CLUE contacts a subclass of window, so you can
pass contacts to any CLX function requiring a window (or drawable), and
any CLX function returning a window can return a CLUE contact.
Second, at the time CLUE was being designed, DRAWABLEs didn't have a
PLIST slot, so the only way to make the association between a window and
its contact was with a hash table. Making CLUE contacts CLX window
objects allowed us to utilize the CLX window-id to window object lookup
in the CLX event code. This eliminates a second lookup and extra
bookkeeping.
The price we pay for this is that you've got to re-compile CLX with
DRAWABLE, WINDOW and PIXMAP defined as CLOS classes, which doesn't seem
like a big deal to me. All the CLX accessor/setf's still work, so the
"CLX interface definition" isn't changed. It seems to me that making
DRAWABLEs etc. CLOS classes doesn't break "the modularity of the
CLX/CLOS/CLUE system", but enhances it.
I'm aware that this is a religious issue and that RWS in particular
dislikes this approach (though I've never really understood why). If
there's community agreement that our approach is wrong, CLUE can be
changed so contacts have a slot that points to their associated window.
That would require replacing "contact" with "(contact-window contact)"
in all our CLX calls, but that's not a big deal (just ugly ;-)
- LaMott
--------
∂29-Jun-88 0350 CL-Windows-mailer X server on TI Explorer
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jun 88 03:50:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa03696; 29 Jun 88 5:59 EDT
Received: from etl.jp by RELAY.CS.NET id ae11529; 29 Jun 88 5:47 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA11463; Wed, 29 Jun 88 18:11:47 JST
Date: Wed, 29 Jun 88 18:11:47 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Subject: X server on TI Explorer
I have heard that there is X server for Symbolics.
I would like to know whether it is possible to port from Symbolics to
TI Explorer and whether there exists a X server program for TI Explorer.
If such a program exists, I would like to know whether it is PD or not
and how could I get it.
Haruyuki Kawabe
Knowledge System
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂30-Jun-88 1652 CL-Windows-mailer CLX Menus
Received: from K.GP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 30 Jun 88 16:52:38 PDT
Received: from K.GP.CS.CMU.EDU by K.GP.CS.CMU.EDU; 30 Jun 88 19:52:12 EDT
To: cl-windows@sail.stanford.edu
Subject: CLX Menus
Date: Thu, 30 Jun 88 19:51:49 EDT
Message-ID: <21516.583717909@K.GP.CS.CMU.EDU>
From: Paul.Birkel@K.GP.CS.CMU.EDU
Would anyone be willing to share a working menu package under CLX,
say a working version of Kerry Kimbroughs' "Windows to the Future"
example? Nothing very fancy needed, just a quick workhorse to get
something running and to use for coding examples/pointers?
Also, where's the "official" CLUE repository for anonymous FTP
currently?
Thanks,
paul
∂01-Jul-88 0906 CL-Windows-mailer Re: CLX Menus
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Jul 88 09:05:55 PDT
Received: by ti.com id AA01790; Fri, 1 Jul 88 11:04:23 CDT
Received: from dsg by tilde id AA01294; Fri, 1 Jul 88 10:53:42 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 1 Jul 88 10:49:59 CDT
Message-Id: <2792764364-4624992@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 1 Jul 88 10:52:44 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Paul.Birkel@K.GP.CS.CMU.EDU
Subject: Re: CLX Menus
Cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: Msg of Thu, 30 Jun 88 19:51:49 EDT from Paul.Birkel@K.GP.CS.CMU.EDU
> Would anyone be willing to share a working menu package under CLX,
> say a working version of Kerry Kimbroughs' "Windows to the Future"
> example? Nothing very fancy needed, just a quick workhorse to get
> something running and to use for coding examples/pointers?
Check out the CLUE release described below.
> Also, where's the "official" CLUE repository for anonymous FTP
> currently?
From our collection of valuable CLUE boilerplate:
----------------------------
A portable implementation of the Common Lisp User interface Environment (CLUE)
is now available in the public domain. Anyone interested may receive source
code and documentation via anonymous ftp from CSC.TI.COM, (internet address
10.7.0.46) in pub/clue.tar.Z A copy will soon be available from
EXPO.LCS.MIT.EDU.
This implementation of CLUE (Version 1.13) may be installed without change in TI
Explorer and Symbolics environments. Other configurations have not yet been
tested. Bug reports and fixes are welcome and should be addressed to one of the
following addresses. The standard X bug report format is nice and is preferred.
clue-bugs@dsg.csc.ti.com
(...im4u!ti-csl!dsg!clue-bugs).
We encourage comments from anyone interested in Lisp user interface programming.
General comments and CLUE issue discussion should be addressed to
cl-windows@sail.stanford.edu or to clue-review@dsg.csc.ti.com.
∂04-Jul-88 0805 CL-Windows-mailer Update on common windows?
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 4 Jul 88 08:05:47 PDT
Received: by tut.cis.ohio-state.edu (5.54/2.0)
id AA13088; Mon, 4 Jul 88 11:07:22 EDT
Date: Mon, 4 Jul 88 11:07:22 EDT
From: welch@tut.cis.ohio-state.edu (Arun Welch)
Message-Id: <8807041507.AA13088@tut.cis.ohio-state.edu>
To: cl-windows@sail.stanford.edu
Subject: Update on common windows?
Last year the following appeared on this mailing list. Can someone
tell me the status of the revision? Sorry about foisting this on the
whole mailing list, but I can't seem to get mail to acorn.
...arun
Date: Fri, 20 Nov 87 10:22 edt
From: eli%acorn@oak.lcs.mit.edu
To: Kimbrough%dsg.csc.ti.com@RELAY.CS.NET
Subject: Re: standard stream windows
Cc: MMcM@SCRC-STONY-BROOK.ARPA, cl-windows@SAIL.STANFORD.EDU
Date: Thu, 19 Nov 87 18:39:13 CST
From: Kerry Kimbrough <Kimbrough%dsg.csc.ti.com@RELAY.CS.NET>
Something that needs to be tackled is the distinction between
character stream i/o and presentation of text (btw, I'm not
talking about Genera presentations). This distinction tends to
be blurred in Lispm window systems.
....
Anyway, this is all a timely topic, and I hope to see more
discussion about CLX, CLOS, and window streams.
This issue is currently being discussed among some of us who
are working on a revision of Common Windows. There is some
sentiment that "windows" and "window streams" are different
beasts. Windows are two dimensional while streams are one
dimensional.
You refer to implementing entire window systems as streams, but
I interpret this as being at a lower level than the interface
presented by Common Windows.
I'd be interested in knowing who would like to work with us
(Gold Hill, Franz, Coral; and hopefully Intellicorp and
Schlumberger are signed up so far) on revisions of Common
Windows.
Eli Wylen, Gold Hill
-------
-------
∂07-Jul-88 1632 CL-Windows-mailer clue-review
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Jul 88 16:32:12 PDT
Received: by ti.com id AA01716; Thu, 7 Jul 88 18:31:37 CDT
Received: from dsg by tilde id AA10588; Thu, 7 Jul 88 18:19:53 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 7 Jul 88 18:15:44 CDT
Message-Id: <2793309291-4345754@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 7 Jul 88 18:14:51 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Cc: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: clue-review
This is to announce the inauguration of a mailing list at
clue-review@dsg.csc.ti.com devoted to discussion of the Common Lisp User
Interface Environment (CLUE). This mailing list is intended to
distribute messages among people interested in using CLUE, porting CLUE
to new platforms, improving CLUE in future versions, sharing CLUE
programs, etc. Requests to join the list may be sent to me directly.
Regards,
Kerry Kimbrough
Texas Instruments
(512) 250-6182
kimbrough@dsg.csc.ti.com
...im4u!ti-csl!dsg!kimbrough
∂18-Jul-88 0248 CL-Windows-mailer window systems
Received: from tor.nta.no by SAIL.Stanford.EDU with TCP; 18 Jul 88 02:45:32 PDT
Posted-Date: 18 Jul 88 11:43 +0100
Received: by tor.nta.no (5.54/3.21)
id AA13614; Mon, 18 Jul 88 11:48:29 +0200
Date: 18 Jul 88 11:43 +0100
From: Arne Lokketangen <arnel%dhmolde.uninett@TOR.nta.no>
To: <cl-windows@sail.stanford.edu>
Message-Id: <142*arnel@dhmolde.uninett>
Subject: window systems
Dear Sirs.
I am using Common Lisp on a VAX-station 2000
running VMS, and would like to be included on
Your mailing list.
I am presently teaching computer science at
Molde College in Norway. My address is:
Arne Lokketangen
dhMolde
Romsdalsgata 5
6400 Molde
Norway
Tel: +47-72-51077
EAN network address: arnel@dhmolde.uninett
Yours sincerely
Arne Lokketangen
∂22-Jul-88 1407 CL-Windows-mailer clue-review bounce list
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Jul 88 14:06:59 PDT
Received: by ti.com id AA00567; Fri, 22 Jul 88 16:06:05 CDT
Received: from dsg by tilde id AA00574; Fri, 22 Jul 88 14:03:01 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 22 Jul 88 13:12:01 CDT
Message-Id: <2794587116-3154490@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 22 Jul 88 13:11:56 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: clue-review bounce list
Sorry, but the following addresses on the clue-review list are unreachable (at
least from my site). Are you folks listening? Please send me an updated address.
T-LUND@lisbet.liu.se.com
moss!ihlpf!clarisse@rutgers.edu
Welch%osu-20@ohio-state.arpa
laubsch@HPL.HP.COM
Regards,
Kerry Kimbrough
(512) 250-6182
∂24-Jul-88 2110 CL-Windows-mailer CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 24 Jul 88 21:10:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00713; 24 Jul 88 23:58 EDT
Received: from etl.jp by RELAY.CS.NET id ad05443; 24 Jul 88 23:42 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA02116; Mon, 25 Jul 88 12:01:57 JST
Date: Mon, 25 Jul 88 12:01:57 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: Kimbrough@dsg.csc.ti.com
Cc: cl-windows@SAIL.STANFORD.EDU, RWS@ZERMATT.LCS.MIT.EDU
In-Reply-To: Kerry Kimbrough's message of Thu, 7 Jul 88 18:14:51 CDT
Subject: CLUE
Dear Mr. Kimbrough,
Please add clue-review%etl.jp@relay.cs.net to the mailing list at
clue-review@dsg.csc.ti.com.
I received CLUE distribution tape from Mr. Pierce of NCR.
May I re-distribute it to interested people in Japan?
And how can I get updates or patches for it?
Thanks in advance.
Sincerely yours,
Haruyuki Kawabe
Knowledge System Department
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂15-Aug-88 0345 CL-Windows-mailer please remove my address from the cl-windows mailing list
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 15 Aug 88 03:45:16 PDT
Received: from kddlab.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA22884; Mon, 15 Aug 88 06:44:10 EDT
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA01856; Mon, 15 Aug 88 19:22:29+0900
Received: by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA17032; Mon, 15 Aug 88 18:30:21+0900
Received: from ken1.ws.sony.junet (ken1.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03192; Mon, 15 Aug 88 17:25:26 jst
Received: by ken1.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01410; Mon, 15 Aug 88 17:26:31 jst
Return-Path: <takegi@ken1.ws.sony.junet>
Message-Id: <8808150826.AA01410@ken1.ws.sony.junet>
Date: 15 Aug 1988 1726-JST (Monday)
From: kddlab!uunet.UU.NET!ken1.ws.sony.junet!takegi@uunet.UU.NET (Kenjyo Takegi)
Cc: takegi%ken1.ws.sony.junet@uunet.UU.NET
To: cl-windows@sail.stanford.edu
Subject: please remove my address from the cl-windows mailing list
Please remove my address from the cl-windows mailing list.
Best regards.
--- Kenjyo takegi
Work station division
Super micro systems group
Sony Corp.
∂31-Aug-88 1206 CL-Windows-mailer CLUE 1.15 availaible
Received: from ti.com by SAIL.Stanford.EDU with TCP; 31 Aug 88 12:06:23 PDT
Received: by ti.com id AA20284; Wed, 31 Aug 88 14:04:36 CDT
Received: from SI by tilde id AA09794; Wed, 31 Aug 88 13:55:49 CDT
Message-Id: <2798045847-9958441@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 31 Aug 88 13:57:27 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Cc: Myjak@tilde.csc.ti.com
Subject: CLUE 1.15 availaible
In-Reply-To: Msg of Tue, 30 Aug 88 17:59:57 CDT from Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
You can grab a copy of the latest version of CLUE that will be
distributed with Xv11 R3 from CSC.TI.COM, the /pub/clue.tar file.
CLUE 1.15 depends on R3 CLX features and bug-fixes. My copy of CLX (not
as many fixes as MIT's version, but much better than R2) is available in
/pub/clx.tar There are also compressed versions in clue.tar.Z and
clx.tar.Z
Also on CSC.TI.COM you will find in /pub/clx.doc or /pub/clx.doc.Z
preliminary CLX documentation. This documentation isn't very pretty,
and the last two chapters aren't finished yet, but it's free!
Please send your comments to Myjak@tilde.csc.ti.com
∂01-Sep-88 0705 CL-Windows-mailer Re: CLUE 1.15 availaible
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Sep 88 07:05:00 PDT
Received: by ti.com id AA27063; Thu, 1 Sep 88 09:03:44 CDT
Received: from SI by tilde id AA00832; Thu, 1 Sep 88 08:49:08 CDT
Message-Id: <2798113899-14047067@SI>
Sender: OREN@SI.csc.ti.com
Date: Thu, 1 Sep 88 08:51:39 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: Bill Janssen <janssen%sw.MCC.COM@MCC.COM>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLUE 1.15 availaible
In-Reply-To: Msg of Wed, 31 Aug 88 18:11:21 CDT from Bill Janssen <janssen%sw.MCC.COM@MCC.COM>
Date: Wed, 31 Aug 88 18:11:21 CDT
From: Bill Janssen <janssen%sw.MCC.COM@MCC.COM>
Subject: Re: CLUE 1.15 availaible
I'd love to get a copy of the documentation, but our machines don't
know where csc.ti.com is. Can you send me the numbers? Thanks.
CSC.TI.COM has internet address 10.7.0.46
∂06-Sep-88 1510 CL-Windows-mailer lispx e-mail distribution list
Received: from rand-unix.arpa by SAIL.Stanford.EDU with TCP; 6 Sep 88 15:10:47 PDT
Received: from ipsy.rand.org by rand-unix.arpa; Tue, 6 Sep 88 14:52:40 PDT
Received: from localhost by ipsy.arpa; Tue, 6 Sep 88 14:54:19 PDT
Message-Id: <8809062154.AA23079@ipsy.arpa>
To: cl-windows@sail.stanford.edu
Cc: Isaac_Salzman <salzman@rand-unix.ARPA>
Subject: lispx e-mail distribution list
Date: Tue, 06 Sep 88 14:54:16 PDT
From: Isaac <salzman%ipsy@rand-unix.ARPA>
I was told by Kerry Kimbrough (kimbrough@@dsg.csc.ti.com) that
people on this list may be interested in the following:
------- Forwarded Message
Received: by rand-unix.arpa; Thu, 1 Sep 88 14:41:24 PDT
Message-Id: <8809012141.AA02332@rand-unix.arpa>
To: lispx@rand-unix.ARPA
Cc: isl@rand-unix.ARPA
Subject: intro to lispx e-mail distribution list
Reply-To: lispx-request@rand-unix.ARPA
Date: Thu, 01 Sep 88 14:41:19 PDT
From: Isaac <salzman@rand-unix.ARPA>
Hello all! This is the beginning of "lispx", a distribution list for
discussing X windows applications in Lisp. This list is starting as
a result of a BOF session held at Xhibition '88 at MIT last
month.
To summarize what was disucussed at Xhibition:
Currently two packages are available for writing X windows applications
in Lisp: CLX, a functional equivalent to Xlib written in Common Lisp,
and CLUE, an object oriented toolkit for X11 written in Common Lisp
which requires PCL (portable common loops) and CLX.
Looks like everyone would like to see all this stuff run under
KCL, and work is being done in that direction. Since CLX is part
of the core X11 distribution it may not be a bad idea to solicit
to X consortium for better of support KCL since it is a NON-proprietary
Common Lisp implementation.
An interest was expressed in more high-level lisp interfaces to
X (i.e. widget sets in lisp?).
Let's start an e-mail distribution list on this topic!
Well, that's basically the bottom line. If anyone cares to add
more....
This list is very small at the moment, hopefully it will increase in
size. After I've heard some feedback I will post the existance of
this list to xpert (assuming that there is at least still an interest
among those that asked to start it!).
The few initial subscibers are (this may be a surprise to a couple
people):
Isaac Salzman, RAND Corp. salzman@rand-unix.ARPA
Darrell Shane, RAND Corp. shane@rand-unix.ARPA
Chris Burdorf, RAND Corp. burdorf@rand-unix.ARPA
Kerry Kimbrough, Texas Instruments kimbrough@dsg.csc.ti.com
James Salem, Thinking Machines Corp. salem@think.com
Bob Bittner, Carnegie Group Inc. bittner%cgi.com@relay.cs.net
Jordan Hubbard, PCS (W. Germany) jkh@violet.berkeley.edu
(what's your new e-mail addr Jordan?)
To subscribe send mail to:
lispx-request@rand-unix.ARPA
Send submissions to:
lispx@rand-unix.ARPA
All submissions will be forwarded immediately (this list is not moderated
or digetsted, etc.). Ciao!
- --
* Isaac J. Salzman ----
* The RAND Corporation - Information Systems Lab /o o/ /
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | |
* AT&T: +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/
* ARPA: salzman@RAND.ORG or salzman@rand-unix.ARPA / | |
* UUCP: ...!{cbosgd,decvax,sdcrdcf}!randvax!salzman | | |
------- End of Forwarded Message
∂07-Sep-88 0735 CL-Windows-mailer Re: lispx e-mail distribution list
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Sep 88 07:34:47 PDT
Received: by ti.com id AA12074; Wed, 7 Sep 88 09:33:27 CDT
Received: from SI by tilde id AA13024; Wed, 7 Sep 88 09:20:08 CDT
Message-Id: <2798633998-264730@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 7 Sep 88 09:19:58 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: cl-windows@sail.stanford.edu
Cc: lispx@rand-unix.ARPA, Isaac_Salzman <salzman@RAND-UNIX.ARPA>,
Richard Harris <harrisr@turing.cs.rpi.edu>
Subject: Re: lispx e-mail distribution list
In-Reply-To: Msg of Tue, 06 Sep 88 14:54:16 PDT from Isaac <salzman%ipsy@RAND-UNIX.ARPA>
Hello all! This is the beginning of "lispx", a distribution list for
discussing X windows applications in Lisp. This list is starting as
a result of a BOF session held at Xhibition '88 at MIT last
month.
...
An interest was expressed in more high-level lisp interfaces to
X (i.e. widget sets in lisp?).
I don't understand why yet another mailing list is required. What's
wrong with CL-WINDOWS@sail.stanford.edu? CL-WINDOWS is where the CLX
design was hammered out, and there are already mailing lists for issues
specific to CLUE and PCL.
It seems to me that "widget" design, and good common-lisp interfaces to
the widgets is of general interest. Lets use CLUE to implement a good
window-system independent CL widget set design, and give the design
discussions wide distribution.
To summarize what was disucussed at Xhibition:
Currently two packages are available for writing X windows applications
in Lisp: CLX, a functional equivalent to Xlib written in Common Lisp,
and CLUE, an object oriented toolkit for X11 written in Common Lisp
which requires PCL (portable common loops) and CLX.
Looks like everyone would like to see all this stuff run under
KCL, and work is being done in that direction. Since CLX is part
of the core X11 distribution it may not be a bad idea to solicit
to X consortium for better of support KCL since it is a NON-proprietary
Common Lisp implementation.
The version of CLX in release 3 of the MIT X11 distribution should run
under KCL. If it doesn't, send bug reports to bug-clx@expo.lcs.mit.edu
It seems to me that the "right" thing to do is make both KCL and CLUE
conform to the common-lisp specification, rather than hack CLUE (or CLX)
to conform to KCL's quirks. Richard Harris <harrisr@turing.cs.rpi.edu>
has patches to KCL which fix several common-lisp incompatibilities. If
you get these, you should be able to run CLUE under KCL. If you still
have problems with CLUE, send bug reports to clue-bugs@dsg.csc.ti.com.
CLUE bug fixes will be posted to clue-review@dsg.csc.ti.com
------- Forwarded Message
Date: Fri, 2 Sep 88 12:25:08 EDT
From: harrisr@turing.cs.rpi.edu (Richard Harris)
Subject: CLUE in KCL
To: clue-review@dsg.csc.ti.com
I am planning to start a mailing list for people who use CLUE or CLX
with KCL, and distribute my patches to people who want them and are on the list.
The list will be set up in a day or two, and I will announce it then.
...
KCL (with akcl-1-50)
(my patches are in a 70k byte file containing a shell script which uses
the unix program ed, and so require that you have exactly KCL with akcl-1-50)
(PCL (8/28/88) seems to work in KCL with akcl-1-50 even without these patches,
except for reentrant compilation (which PCL needs occasionally))
(CLX uses patch E, and CLUE uses patch G)
A) load-time-eval support (for pcl; pcl no longer uses load-time-eval)
cmpeval.lsp: c1symbol-fun: reverse checks for (macro-function fname) and
(get fname 'compiler-macro)
pcl/kcl-low: load-time-eval definition:
(defmacro load-time-eval (form) `(progn ,form))
(si:define-compiler-macro load-time-eval (form) `'(si:|#,| . ,form))
B) &environment fix
defmacro.lsp
cmplam.lsp
pcl/defsys: skip kcl-patches
C) describe and inspect of structures
describe.lsp
D) eval-when handling, symbol interning, #, handling ...
1) interning of symbols and evaluation of #, at load time is much closer
to what happens at read time,
2) top-level package operations do not (and do not need to) get run before
anything else in the file can be loaded,
3) the functions MAKE-PACKAGE, IN-PACKAGE, SHADOW, SHADOWING-IMPORT,
EXPORT, UNEXPORT, USE-PACKAGE, UNUSE-PACKAGE, IMPORT, PROVIDE, REQUIRE, and PROCLAIM
behave as though calls to them were wrapped in (EVAL-WHEN (LOAD COMPILE EVAL) ...)
and all other function calls behave as though they were wrapped in
(EVAL-WHEN (LOAD EVAL) ...)
4) EVAL-WHEN is useful in macros again, and
5) the CL macros DEFMACRO, DEFSTRUCT, DEFVAR, DEFPARAMETER, DEFCONSTANT, DEFTYPE,
DEFSETF, and DEFINE-SETF-METHOD wrap (EVAL-WHEN (LOAD COMPILE EVAL) ...)
around the forms they produce.
cmpaux.c: change set_VV()
read.d: string_to_object: use standard_read_object_non_recursive instead of read_object
to avoid a problem with #0= (spurious Duplicate definitions message)
sfasl.c: use initialize_file() in fasload()
unixfasl.c: add initialize_file() and use it in fasload()
defstruct.lsp: use eval-when in CL macros
evalmacros.lsp: use eval-when in CL macros
predlib.lsp: use eval-when in CL macros
typep: (typep v '(array x)) works now (for all v and (legal) x)
setf.lsp: use eval-when in CL macros
cmpenv.lsp: vv changes, add-* changes
cmpmain.lsp: changes to data-file output
call t1expr-top rather than t1expr
cmptop.lsp: vv changes,top-level changes,add t1expr-top,change ctop-write,...
sys_kcl.c: use initialize_file()
basic_kcl.c: a simpler alternative to sys_kcl.c (use with makebasic and basic.lsp)
makebasic: a makefile for basic_kcl
basic.lsp: loaded by basic_kcl.c; defines (si:compile-system-files)
cmpinit.lsp: I deleted this file
E) add (unsigned_byte 8) array-element-type (for clx)
array.c: add aet_byte support
gbc.c: add aet_byte support
number.c: add fixbyte()
sequence.d: add aet_byte support
typespec.c: add aet_byte support
arraylib.lsp: find-subtype macro for use in make-array
cmptype.lsp: type>= change, ...
F) recursive compilation now works
G) hooks to allow clue to use pcl instances as streams
------- End of Forwarded Message
∂20-Sep-88 2342 CL-Windows-mailer X Consortium priorities
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 23:42:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 23:37:49 PDT
Date: 20 Sep 88 23:37 PDT
From: masinter.pa@Xerox.COM
Subject: X Consortium priorities
To: cl-windows@sail.stanford.edu
Message-ID: <880920-233749-5579@Xerox>
I noted in the Final Minutes of 8/22/88 Advisory Meeting of the X consortium
that under "What should the Consortium be working on next?" that the Common Lisp
interface to X was last in priority. My reading is that CLX for future versions
of X are at risk. Anybody have a different interpretation?
...
11. What should the Consortium be working on next?
....
b. A collection of these items was chosen and a very informal straw poll
was taken. Each person was allowed to vote for 3 items (the
generally agreed upon maximum number of major projects that could be
worked on at any one time) that he or she felt should be the focus of
the Consortium's efforts over the next year or so. This was not
intended to be a referendum on whether or not particular issues where
important, but rather a "finger to the wind" to see what areas the
Consortium as a whole should pursue in the near term. The results,
in descending order, were:
Internationalization 16
Core Widgets 12
Validation suites and Xt testing 11
Security 9
Data Interchange 5
ADE 5
Fortran 4
Image Processing 3
Font Server 3
X over Serial Lines 2
X11.1 2
Creating 100 good X applications 2
Benchmarking 1
Ada 1
Video 0
Run-time Extensibility 0
PostScript 0
Color Database 0
CLX 0
"
∂21-Sep-88 0650 CL-Windows-mailer Re: X Consortium priorities
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 06:50:05 PDT
Received: by ti.com id AA01692; Wed, 21 Sep 88 08:48:08 CDT
Received: from SI by tilde id AA23229; Wed, 21 Sep 88 08:33:42 CDT
Message-Id: <2799840811-3350599@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 21 Sep 88 08:33:31 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: masinter.pa@XEROX.COM
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: X Consortium priorities
In-Reply-To: Msg of 20 Sep 88 23:37 PDT from masinter.pa@XEROX.COM
Date: 20 Sep 88 23:37 PDT
From: masinter.pa@XEROX.COM
Subject: X Consortium priorities
I noted in the Final Minutes of 8/22/88 Advisory Meeting of the X consortium
that under "What should the Consortium be working on next?" that the Common Lisp
interface to X was last in priority. My reading is that CLX for future versions
of X are at risk. Anybody have a different interpretation?
Yes. My reading is that CLX doesn't need much work. Notice that XLIB
(as well as lots of other things) wasn't on the list of "things to
work on next". Surely you don't expect it to go away...
∂21-Sep-88 0748 CL-Windows-mailer X Consortium priorities
Received: from VAX.BBN.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 07:48:13 PDT
From: Dan Cerys <cerys@bbn.com>
Sender: cerys@bbn.com
To: masinter.pa@XEROX.COM
CC: cl-windows@SAIL.STANFORD.EDU
In-reply-to: masinter.pa@XEROX.COM's message of 20 Sep 88 23:37 PDT <880920-233749-5579@Xerox>
Subject: X Consortium priorities
Date: Wed, 21 Sep 88 10:35:41 EDT
I noted in the Final Minutes of 8/22/88 Advisory Meeting of the X consortium
that under "What should the Consortium be working on next?" that the Common Lisp
interface to X was last in priority. My reading is that CLX for future versions
of X are at risk. Anybody have a different interpretation?
I don't think there should be a major worry here. CLX, even with X protocol
changes, has been very solid-looking lately. Much credit here goes to
LaMott and Bob, who have done a fine job of the bulk of the implementation.
So, in asking "What should the Consortium be working on next?", I'd be
surprised to find a stable piece of work like CLX to be a top answer.
Dan
∂21-Sep-88 0934 CL-Windows-mailer Re: X Consortium priorities
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 09:34:16 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 88 09:28:45 PDT
Date: 21 Sep 88 09:29 PDT
From: Rao.pa@Xerox.COM
Subject: Re: X Consortium priorities
In-reply-to: LaMott Oren <Oren@Home.csc.ti.com>'s message of Wed, 21 Sep 88
08:33:31 CDT
To: LaMott Oren <Oren@Home.csc.ti.com>
cc: masinter.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU
Message-ID: <880921-092845-5994@Xerox>
True, CLX doesn't need much work (at least not in the context of the whole X
effort). But I don't think most of the X Consortium members would even know
this. The fact (unfortunate though it may seem to us) is that the world at
large doesn't give a damn about lisp.
-- Ramana
∂22-Sep-88 1149 CL-Windows-mailer Re: International character sets
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Sep 88 11:48:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 88 11:32:44 PDT
Date: 22 Sep 88 11:27 PDT
From: fischer.pa@Xerox.COM
Subject: Re: International character sets
In-reply-to: masinter.pa's message of 21 Sep 88 23:35 PDT
To: cl-windows@sail.stanford.edu
Message-ID: <880922-113244-2701@Xerox>
You should consider adopting the Xerox NS character encoding to enable
international character sets. Its a well thought out standard in use everyday
by thousands of users. Why reinvent the wheel?
(ron)
∂22-Sep-88 1430 CL-Windows-mailer Using clx with kcl
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Sep 88 14:30:16 PDT
Received: from relay2.cs.net by RELAY.CS.NET id bp09994; 22 Sep 88 14:37 EDT
Received: from waterloo.edu by RELAY.CS.NET id da10542; 22 Sep 88 14:03 EDT
Received: from watsnew by watmath; Wed, 21 Sep 88 15:45:38 EDT
Received: by watsnew; Wed, 21 Sep 88 15:45:31 EDT
Date: Wed, 21 Sep 88 15:45:31 EDT
From: Andrew Thomas <andrewt@watsnew.waterloo.edu>
Message-Id: <8809211945.AA00481@watsnew>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Using clx with kcl
I am not sure if this is the right place to be asking this, but I know of
no other address. Please advise.
I am trying to use clx with kcl on a vax running Ultrix 2.0. Clx tries to
load tcp for kcl. There should be a .c file called kcltcp.c which was not
included with the release that I have of X11 (clx). Does anybody out there
have this file and would be willing to send it to me? Also, the file
tcpinit.lisp used with kcl has a call to (si:faslink). This symbol is not
recognized by kcl. It is not defined anywhere in the clx distribution, nor
does it appear in the common lisp manual (Guy Steele). Is this an oversight
on my part somewhere?
Any help in either or both of these areas would be most appreciated.
Andrew Thomas Pattern Analysis and Machine Intelligence Group
Dept of Systems Design University of Waterloo
∂26-Sep-88 0923 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:22:08 PDT
Received: from fafnir.think.com by Think.COM; Mon, 26 Sep 88 03:48:25 EDT
Return-Path: <salem@Think.COM>
Received: from sauron.think.com by fafnir.think.com; Mon, 26 Sep 88 03:45:56 EDT
Received: by sauron.think.com; Mon, 26 Sep 88 03:45:54 EDT
Date: Mon, 26 Sep 88 03:45:54 EDT
From: salem@Think.COM
Message-Id: <8809260745.AA03417@sauron.think.com>
To: cl-windows@Think.COM
Subject: Needed: Info on LISP X based toolkits
I putting together of summary of X Windows toolkits being written on top
CLX or, preferably, on top of CLUE.
I would like to know about all efforts no matter how small. Thinking
Machines hopes to help standarize a toolkit and is willing to help with design,
implementation, and testing. Please e-mail to me (salem@think.com) and I
will summarize to this list.
I'm particularly interested in :
- the toolkit's contents (e.g. menues ? buttons ? sliders ? text boxes ? etc.)
- "style"
- CLUE based ?
- Current status (e.g. designed ? implemented ? staffed ?)
- Availability
and whatever else you'd like (try e-mailing a RLE screen dump !)
Any hints/pointers to further sources of information will be greatly
appreciated.
Thanks !
-- jim
salem@think.com
{rutgers, harvard, mit-eddie, . . .}!think!salem
Thinking Machines Corporation, 245 First St., Cambridge MA 02142
(617) 876-1111
∂26-Sep-88 1019 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 10:19:28 PDT
Received: from fafnir.think.com by Think.COM; Mon, 26 Sep 88 13:17:19 EDT
Return-Path: <peo@Think.COM>
Received: from sauron.think.com by fafnir.think.com; Mon, 26 Sep 88 13:16:05 EDT
Received: from ARARAT.THINK.COM by sauron.think.com; Mon, 26 Sep 88 13:16:02 EDT
Date: Mon, 26 Sep 88 13:16 EDT
From: Paul E. Oppenheimer <peo@Think.COM>
Subject: Needed: Info on LISP X based toolkits
To: salem@Think.COM, cl-windows@Think.COM
In-Reply-To: <8809260745.AA03417@sauron.think.com>
Message-Id: <19880926171637.9.PEO@ARARAT.THINK.COM>
Jim Salem,
How do I get started in LISP X?
Thank you.
Paul Oppenheimer
Received: from Think.COM by fafnir.think.com; Mon, 26 Sep 88 13:13:12 EDT
Received: from SAIL.Stanford.EDU by Think.COM; Mon, 26 Sep 88 13:14:14 EDT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:22:08 PDT
Received: from fafnir.think.com by Think.COM; Mon, 26 Sep 88 03:48:25 EDT
Return-Path: <salem@Think.COM>
Received: from sauron.think.com by fafnir.think.com; Mon, 26 Sep 88 03:45:56 EDT
Received: by sauron.think.com; Mon, 26 Sep 88 03:45:54 EDT
Date: Mon, 26 Sep 88 03:45:54 EDT
From: salem@Think.COM
Message-Id: <8809260745.AA03417@sauron.think.com>
To: cl-windows@Think.COM
Subject: Needed: Info on LISP X based toolkits
I putting together of summary of X Windows toolkits being written on top
CLX or, preferably, on top of CLUE.
I would like to know about all efforts no matter how small. Thinking
Machines hopes to help standarize a toolkit and is willing to help with design,
implementation, and testing. Please e-mail to me (salem@think.com) and I
will summarize to this list.
I'm particularly interested in :
- the toolkit's contents (e.g. menues ? buttons ? sliders ? text boxes ? etc.)
- "style"
- CLUE based ?
- Current status (e.g. designed ? implemented ? staffed ?)
- Availability
and whatever else you'd like (try e-mailing a RLE screen dump !)
Any hints/pointers to further sources of information will be greatly
appreciated.
Thanks !
-- jim
salem@think.com
{rutgers, harvard, mit-eddie, . . .}!think!salem
Thinking Machines Corporation, 245 First St., Cambridge MA 02142
(617) 876-1111
∂27-Sep-88 0110 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 Sep 88 01:09:57 PDT
Received: from fafnir.think.com by Think.COM; Tue, 27 Sep 88 04:08:17 EDT
Return-Path: <salem@Think.COM>
Received: from sauron.think.com by fafnir.think.com; Tue, 27 Sep 88 04:07:27 EDT
Received: by sauron.think.com; Tue, 27 Sep 88 04:07:24 EDT
Date: Tue, 27 Sep 88 04:07:24 EDT
From: salem@Think.COM
Message-Id: <8809270807.AA07980@sauron.think.com>
To: peo@Think.COM
Cc: cl-windows@Think.COM
In-Reply-To: Paul E. Oppenheimer's message of Mon, 26 Sep 88 13:16 EDT <19880926171637.9.PEO@ARARAT.THINK.COM>
Subject: Needed: Info on LISP X based toolkits
Date: Mon, 26 Sep 88 13:16 EDT
From: Paul E. Oppenheimer <peo@Think.COM>
Jim Salem,
How do I get started in LISP X?
Thank you.
Paul Oppenheimer
1) Read the X doc. and CLX manual. Lew Tucker may have extra copies
2) Load up CLX {Alex Singer is trying to do this on a Sun-4}.
∂27-Sep-88 0417 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 Sep 88 04:17:31 PDT
Received: from fafnir.think.com by Think.COM; Tue, 27 Sep 88 07:15:41 EDT
Received: from Think.COM by fafnir.think.com; Tue, 27 Sep 88 07:14:48 EDT
Return-Path: <jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK>
Received: from NSS.Cs.Ucl.AC.UK by Think.COM; Tue, 27 Sep 88 07:15:16 EDT
Message-Id: <8809271115.AA11670@Think.COM>
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03052; 27 Sep 88 10:20 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa13038;
27 Sep 88 10:59 BST
To: cl-windows@Think.COM
In-Reply-To: salem@com.think's message of Tue, 27 Sep 88 04:07:24 EDT <8809270807.AA07980@sauron.think.com>
Subject: Needed: Info on LISP X based toolkits
Date: Tue, 27 Sep 88 11:00:44 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
This is indeed good advice. Now all we need to do is find the CLX manual.
∂27-Sep-88 0850 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Sep 88 08:49:57 PDT
Received: by ti.com id AA19939; Tue, 27 Sep 88 10:47:54 CDT
Received: from dsg by tilde id AA11919; Tue, 27 Sep 88 10:31:50 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 27 Sep 88 10:31:47 CDT
Message-Id: <2800366368-8475983@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 27 Sep 88 10:32:48 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: Needed: Info on LISP X based toolkits
In-Reply-To: Msg of Tue, 27 Sep 88 11:00:44 BST from jpff%maths.bath.ac.uk@NSS.CS.UCL.AC.UK
Mike Myjak (Myjak@tilde.csc.ti.com) is developing a CLX manual which is
analogous to the Xlib manual, presenting info about the data types and syntax of
CLX, as well as the underlying protocol semantics and some tips about usage.
His latest version is now available for anonymous ftp from host csc.ti.com,
directory /pub, filename clx.doc or clx.doc.Z (compressed).
∂05-Oct-88 2003 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 20:02:47 PDT
Received: from fafnir.think.com by Think.COM; Wed, 5 Oct 88 22:17:55 EDT
Received: from Think.COM by fafnir.think.com; Wed, 5 Oct 88 22:59:49 EDT
Return-Path: <lanning.pa@xerox.com>
Received: from Xerox.COM by Think.COM; Wed, 5 Oct 88 22:17:43 EDT
Redistributed: CommonLoops.pa
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 19:50:06 PDT
Date: 5 Oct 88 19:50 PDT
From: lanning.pa@xerox.com
Subject: Re: Needed: Info on LISP X based toolkits
In-Reply-To: salem@Think.COM's message of Mon, 26 Sep 88 03:45:54 EDT
To: cl-windows@Think.COM, CommonLoops.pa@xerox.com
Message-Id: <881005-195006-2101@Xerox>
I would like to take this opportunity to flame about CLUE, in the hope that
somebody out there will take the time to educate me. I hope this stirs up
a debate on both lists.
[Note: when I say "lisp", I mean Common Lisp. And CLOS is an official part
of Common Lisp.]
CLUE claims to be an object-oriented, portable user-interface toolkit
written in lisp. To quote from the manual:
CLUE could be described as a translation of the X-Toolkit "intrinsics"
into the domain of Common Lisp and CLOS.
The problem is that this is modeling a large object-oriented Lisp program
on the X-Toolkit. Now if the X-Toolkit were a great example of o-o
programming, or if Lisp were no better at o-o programming than C, this
might make sense. But if those statements were true, I can't see that Lisp
has anything to offer beyond C, and I think we should just trade in our
()'s for {}'s.
There is one possible reason for basing CLUE on the X-Toolkit: if there
were a way of importing C code from the toolkit in a way that made it
follow the CLUE protocol exactly. That could win because we (Lisp'ers)
could take advantage of their (C'ers) code without having to think twice.
But I haven't heard anybody mention this possibility. Even if this were
possible, there is no portable way to import foreign code. Finally, this
argument is based entirely on economics. Not that I have much against
economics, but I don't think it is the only (or even the major) measure of
worth.
The history of o-o programming and window environments are closely coupled.
With lisp we can do much more that duplicate some other conception of a UI
toolkit. But this will take time and effort. CLOS is a new and unique
language; it is elegant, powerful, efficient (well, maybe), and fun. We
have not had enough experience to understand what the "correct" style of
programming in CLOS is, or know how it will change the way we think about
programming. What is needed is not a premature UI toolkit standard based
on some impoverished language's notion of programming, but a long-term
effort by a large community to try to understand what CLOS really is, what
it is really good for, and what it says about the ways to construct such a
system.
Let a thousand systems bloom. And for god's sake, let them bloom in public
where we can all appreciate them and learn from them.
Now that I've stepped on almost everybody's toes, is there anybody out
there with something to say? Speak up now...
-smL
∂06-Oct-88 0020 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 00:19:55 PDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 00:16:12 pdt
Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 00:15:49 pdt
Full-Name: Warren Harris
To: lanning.pa@Xerox.COM
Cc: cl-windows@sail.stanford.edu, commonloops.pa@xerox.com
Cc: bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com
Subject: Re: Needed: Info on LISP X based toolkits
In-Reply-To: Your message of "05 Oct 88 19:50:00 PDT."
<881005-195201-2107@Xerox>
Date: Thu, 06 Oct 88 00:15:45 PDT
Message-Id: <8041.592125345@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
> I would like to take this opportunity to flame about CLUE, in the hope that
> somebody out there will take the time to educate me. I hope this stirs up
> a debate on both lists.
About a year and a half ago there was a long discussion between Mike
McMahon, Robert Scheifler and myself regarding whether CLX should be
required to be object-oriented or not. I'm just wondering if a year and a
half and a CLUE later, if there isn't some new insight or consensus in this
area.
As Mike pointed out, there should be several abstract layers to a window
system:
1. definition of the virtual console
- the X server protocol
2. language bindings for level (1)
- CLX
3. window/stream objects
- requires CLOS
- requires CL streams to be implemented as objects
4. access to the window manager (?)
5. a full UIMS system (??)
One of the fundamental questions raised was whether (2) should be visible
from (3) or not -- that is, should the programmer know anything about CLX
in order to program his native "window system" (albeit Genera, Common
Windows, etc.). The answer to this should be no, since the goal is to
provide the programmer with a nice high-level interface environment, and
backwards compatibility when and if (3) is reimplemented atop CLX. In this
case, it is irrelevant whether CLX is implemented with objects or not.
However, when the issue of portability arises, the programmer will be
forced to revert to CLX (being a part of the CL specification), or some
layer defined on top of CLX (such as CLUE). The question arises again
whether CLX should be visible to this new layer (call it (2.5)). In this
case the answer is probably yes, since you are undoubtedly programming to
extend this lowest common denominator. Now the implementation of CLX *is*
relevant.
One might argue that level (3) might be entirely adopted by CL and
consequently the issue of its portability goes away. CLUE might be viewed
as an attempt at this, but it has taken the approach of leaving various
parts of CLX visible (so it is really a (2.5)). Adopting a full level (3)
would pretty much leave (2) obsolete, and since level (3) would then have
to be at least as powerful as (2), we would consequently be programming to
just a different version of (2). This argues for the (2.5) (CLUE)
approach: use some of CLX when appropriate, and use object-oriented
programming when we must extend it.
Several objections have been raised to object-orienting CLX. One is that
the window system protocol must be well thought out:
> I should also point out that the message passing LISP machine window
> system has a big pitfall. One must be crystal clear on the contract of
> those messages, i.e. on the window protocol. In some cases, this is
> done reasonably well; for example, there is a proper distinction between
> :SET-EDGES and :CHANGE-OF-SIZE-OR-MARGINS. However, no such factoring
> out has been done for :EXPOSE. This makes the interposition of
> application specific behavior problematic, and quite subject to the
> whims on flavor method combination.
This is really a no-op argument. Why wasn't the lisp machine window system
protocol fixed or enhanced? If the real reason was backwards
compatibility, we're not faced with that problem while trying to define a
standard. Hopefully our past experience with the lisp machine and
sufficient experience with CLX will help us standardize on both a necessary
and sufficient protocol.
Another objection raised was the violation of low level contracts by
subclasses of the window class:
> For similar reasons, I object to
> the methodology in some window systems of building cursor-following
> graphics by means of daemons on the fundamental graphics methods. By
> doing so, you completely muddle the contract of those methods, and almost
> guarantee that 50% of the graphics library routines you might want to
> call won't work in your window.
I argue that this is exactly what object-oriented programming is for. How
can you define "won't work"? Violation of the programmer's intention? If
the real worry is that critical subsystems will seize up because we've
redefined some system method, this is not possible. Since the X server is
communicated with through a well defined (non object-oriented) protocol,
the server will never freeze because some client defined a bad application.
The application simply will not run.
I must point out that I believed all these objections for a while, but
after trying to define my own (2.5) window system, I realized that 50% of
it was simply shadowing what my level (2) protocol (an Xlib foreign
function interface) already provided. There were window, font, pixmap,
display and other objects that corresponded directly to X concepts. There
were methods that directly corresponded to X requests (xe:resize was
equivalent to xlib:XConfigureWindow). I had given the programmer the
ability to override or attach daemons to X operations (which is what I
wanted to accomplish, as does CLUE). The disadvantage was that I had
succeeded in giving the programmer a whole new way of naming the same
operations. (As an aside: I never understood why CLX didn't use the same
naming conventions as Xlib. Being unfortunate and sometimes having to
resort to C, that's one more set of bindings I have to learn!)
I'm not really suggesting that CLX exactly mimic Xlib. On the contrary I
would like to see some of Xlib's concepts eradicated from CLX. An example
is the distinction between font and font-info structures. I think these
are in Xlib simply as an excuse for not having multiple return value and
keyword parameters. Why should the user have to know what properties of a
font reside in the font itself, and what properties reside in the "info"
structure? Lisp offers many advantages over C, not the least of which is
the ability to define dynamically scoped macros such as with-state which
greatly enhance the efficiency of CLX while making the programmer's job
easier. The fact that C can't do this is unfortunate. C programmers have
to think harder.
I believe CLX should be modernized to the point of embracing
object-oriented programming. In combination with CLOS, it would provide an
extensible platform upon which to build a level (3), (4) or (5) interface
system. The higher levels would not be confined to expose any of CLX or X
server concepts, but would be allowed to if they so desired. CLUE could be
implemented on such a platform in a *portable* way. (One of the objections
I have to CLUE is that you must bastardize your version of CLX to run it.
Some day this won't be possible.)
I object to CLUE for several reasons. Primarily, it seems to be an excuse
for what CLX is not. I'm not saying the concept of a Common Lisp User
Environment should be eliminated, but we should rethink what we mean by
supporting various levels of a window system. I think this means providing
a set of classes which understand both the X server and the necessities of
CL (such as streams), and a means of extending these classes when
*necessary*. CLX already makes a feeble attempt at objects with
defstructs. If it really meant what it said about the various levels in a
window system, why didn't it just pass around X id's as integers? That's
what Xlib does. (CLX programmers actually get handed these ids in
event-handler routines. They don't tell you what to do with them thought
(like how to lookup the associated xlib:window object).)
I also object to CLUE as it stands for other reasons. For one, the degree
to which CLUE is object-oriented is completely ad hoc. Why can't I
specialize the xlib:font or xlib:display class? (I actually tried to do
this recently, in the same way CLUE redefines xlib:window. Then I realized
that xlib:display is a subtype of xlib:buffer for *efficiency* reasons!)
Related to this is the fact that none of the operations on the classes
xlib:drawable, xlib:window and xlib:pixmap were made generic. If I want to
specialize xlib:window or xlib:contact in CLUE, why can't I write a
map-window method? (Was this in the name of efficiency or what?)
Finally, the notion of callbacks seems more like a throwback to C to me.
Perhaps this is what Lanning is alluding to in his comments about the
XToolKit. Why aren't these callbacks generic functions which can be
overridden or inherited by subclasses of the class for which they're
defined? That would seem cleaner and more straight forward to me.
Perhaps the primary consideration in the back of the CLX implementors heads
is that of efficiency -- will object-oriented programming slow down CLX too
much? Maybe this is the real motivation behind the cursor-following
graphics argument. If this consideration is relevant for CLX, then isn't
it relevant for all object-oriented programs? Or are there classes of
applications that demand efficiency at the cost of extensibility? Is CLX
such an application? I remember the same arguments being made for the CLOS
meta-object protocol, Smalltalk contexts, etc. I think if we're going to
take that kind of attitude ("object-oriented programming is ok for fooling
around, but when it comes to 'production quality code'...") we're kidding
ourselves.
I'm sorry if the flames are hot. I appreciate the insight and effort that
went into both CLX and CLUE. CLUE is a step in the right direction because
it manifests X concepts in an extensible way. I just think we would be
premature to adopt either of them at their current conceptualization.
Since CLUE goes against Scheifler and McMahon's original considerations
about encapsulating the lowest level of the window system, I'm curious what
they think now that it seems to have caught on.
Warren Harris
HP Labs
∂06-Oct-88 0517 CL-Windows-mailer at least one's blooming
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 05:16:50 PDT
Received: from fafnir.think.com by Think.COM; Thu, 6 Oct 88 07:30:20 EDT
Received: from Think.COM by fafnir.think.com; Thu, 6 Oct 88 08:13:46 EDT
Return-Path: <@killington.lcs.mit.edu:RWS@zermatt.lcs.mit.edu>
Received: from EXPO.LCS.MIT.EDU by Think.COM; Thu, 6 Oct 88 07:30:07 EDT
Received: by expo.lcs.mit.edu; Thu, 6 Oct 88 08:13:54 EDT
Date: Thu, 6 Oct 88 08:14 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: at least one's blooming
To: lanning.pa@xerox.com, cl-windows@Think.COM, CommonLoops.pa@xerox.com
In-Reply-To: <881005-195006-2101@Xerox>
Message-Id: <19881006121402.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 5 Oct 88 19:50 PDT
From: lanning.pa@xerox.com
What is needed is not a premature UI toolkit standard
Who said anything about CLUE being a standard (adopted by whom)?
Let a thousand systems bloom. And for god's sake, let them bloom in public
where we can all appreciate them and learn from them.
Thankfully, TI is taking on the burden of making one system bloom, and
bloom in public. If you have specific criticisms of CLUE or suggestions
for improvements, I'm positive the CLUE folks would love to have your
input. They've been quite responsive to other people's comments. If
you've got a better system in mind, by all means describe it, and go off
and implement it and make it public.
∂06-Oct-88 0809 CL-Windows-mailer CLUE and CLX
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 08:09:16 PDT
Received: by expo.lcs.mit.edu; Thu, 6 Oct 88 09:43:29 EDT
Date: Thu, 6 Oct 88 09:43 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: CLUE and CLX
To: harris%hplwhh@hplabs.hp.com, lanning.pa@xerox.com
Cc: cl-windows@sail.stanford.edu, commonloops.pa@xerox.com,
bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com
In-Reply-To: <8041.592125345@hplwhh>
Message-Id: <19881006134336.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 06 Oct 88 00:15:45 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
As an aside: I never understood why CLX didn't use the same
naming conventions as Xlib.
I'm not sure exactly what you mean by "the same" here. We wanted the
CLX stuff in it's own package, and it didn't seem to make too much sense
to me to put in a redundant prefix "X" (e.g. xlib:x-create-window).
Also, Xlib uses CapitalizationToDistinguishWords, and the general CL
convention is-to-use-hyphens, and CLX follows that convention. The CLX
interface was largely defined "ignorant of Xlib", so as to keep an open
mind about how it should be structured. After the fact, we did do a
comparison, and my recollection is that they are reasonably close. But,
I think CLX kept a little closer to the names used in the protocol spec,
whereas Xlib kept a little closer to names that were used in X10.
On the contrary I
would like to see some of Xlib's concepts eradicated from CLX. An example
is the distinction between font and font-info structures.
There are no font-info structures in CLX, in case someone was confused
by an implication here.
I believe CLX should be modernized to the point of embracing
object-oriented programming.
I would be interested in understanding more specifically what you have
in mind.
If it really meant what it said about the various levels in a
window system, why didn't it just pass around X id's as integers?
The only reason Xlib doesn't pass around an "object" for a resource is
because of garbage collection problems. Early Xlibs (previous versions
of X) went back and forth on this one, trying to do what CLX does but
failing due to the C environment. The bundling exists because it is
very convenient.
CLX programmers actually get handed these ids in
event-handler routines.
Yes, there were efficiency arguments here, perhaps inconsequential ones.
They don't tell you what to do with them thought
(like how to lookup the associated xlib:window object).
The CLX doc does tell you to use make-window to perform this mapping.
Perhaps the primary consideration in the back of the CLX implementors heads
is that of efficiency -- will object-oriented programming slow down CLX too
much?
That wasn't the motivation. Partly it was an issue of whether a single
object system was sufficiently stable and standardized to be able to
make it a requirement (the answer seemed to be No). Also lurking around
was the notion of being able to use essentially the same interface in
other lisp dialects. Also, it wasn't at all obvious that we could
quickly reach consensus on what an O-O CLX should look like (in terms of
raising CLX to a higher level). And, it wasn't at all obvious that CLX
should show through at the higher level (all the issues you enumerated).
Since CLUE goes against Scheifler and McMahon's original considerations
about encapsulating the lowest level of the window system, I'm curious what
they think now that it seems to have caught on.
I have too many flowers blooming right now, and I have a hard time
keeping up with all the details of all of them. I do not consider
myself a Lisp/OOPS expert in the same league as many of the rest of you
out there; I'd much rather have you experts combine forces to produce
the right thing.
∂06-Oct-88 0821 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 08:20:55 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA18474; Thu, 6 Oct 88 08:09:22 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA06158; Thu, 6 Oct 88 08:12:15 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA02232; Thu, 6 Oct 88 08:12:16 PDT
Message-Id: <8810061512.AA02232@suntana.sun.com>
To: Warren Harris <harris%hplwhh@hplabs.hp.com>
Cc: lanning.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU,
commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com,
cline%hplwhh@hplabs.hp.com
Subject: Re: Needed: Info on LISP X based toolkits
In-Reply-To: Your message of Thu, 06 Oct 88 00:15:45 -0700.
<8041.592125345@hplwhh>
Date: Thu, 06 Oct 88 08:12:14 PDT
From: kempf@Sun.COM
I pretty much agree with what Warren had to say in his note except
for the following:
> 1. definition of the virtual console
> - the X server protocol
> 2. language bindings for level (1)
> - CLX
> 3. window/stream objects
> - requires CLOS
> - requires CL streams to be implemented as objects
This assumes (as does the rest of Warren's note) that the host window
system is and will always be X. There are currently Common Lisp implementations
running on Mac's and PC's which don't target to X host systems. Furthermore,
both NeWS and Display Postscript (which will be on the NeXT machine) aren't
X based.
The big win of Common Lisp in general is that it defines a high level
virtual machine which insulates application developers from the underlying
hardware. It seems as if a "window virtual machine" combining Level 2 & 3
insulating application developers from the underlying host window systems
could make window based applications more portable.
Since the window virtual machine is likely to require stream objects,
it seems more appropriate to implement it as a combination of 2 & 3. Thus
the underlying window system would remain opaque to the application, and
the window virtual machine level could be nicely object-oriented.
The "thousand flowers" in Stan's original note could then bloom at the
toolkit level, since different applications are likely to require different
ways of interacting with them.
jak
∂06-Oct-88 1113 CL-Windows-mailer More wood for the flames...
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 6 Oct 88 11:13:14 PDT
Received: by tut.cis.ohio-state.edu (5.54/2.880920)
id AA22830; Thu, 6 Oct 88 14:11:02 EDT
Date: Thu, 6 Oct 88 14:11:02 EDT
From: welch@tut.cis.ohio-state.edu (Arun Welch)
Message-Id: <8810061811.AA22830@tut.cis.ohio-state.edu>
To: cl-windows@sail.stanford.edu, common-loops@xerox.com
Subject: More wood for the flames...
[our mailer died on the first try on this, hopefully you're not seeing
this twice]
1) Into all this discussion about making CLX more o-o-like, I'd like to
throw out the following question: Why X at all? Why not a Postscript
based window system, since Postscript is already an o-o language? The
obvious objection is that NeWS only runs on Suns, I'll admit, but then
again, X only runs on some machines too...
2) I'd like to propose that the discussion move off of common-loops
onto common-windows.
3) A request for info: One of the thousand blooms (shades of thousand
points of light ?:-) is CLUE. Is anyone working on other interfaces?
What happened to the Common-Windows consortium (Yes, I'll admit that
there are objections to common-windows too)? The last I ever heard
from them was an offer for people to help them...
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂06-Oct-88 1121 CL-Windows-mailer Re: CLX and OOP
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 11:21:48 PDT
Received: by ti.com id AA19400; Thu, 6 Oct 88 13:19:19 CDT
Received: from dsg by tilde id AA22119; Thu, 6 Oct 88 13:08:13 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 13:07:46 CDT
Message-Id: <2801153312-6211532@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 6 Oct 88 13:08:32 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: harris%hplwhh@hplabs.hp.com, lanning.pa@Xerox.COM,
cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM,
bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com
Subject: Re: CLX and OOP
In-Reply-To: Msg of Thu, 6 Oct 88 09:43 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Regarding the proper relationship between CLX and OOP: First, I believe there
will be little disagreement with the notion that this relationship must be
defined in terms of CLOS.
But one idea that occurs immediately is that CLX could be "CLOS-ified" in a
straight-forward way by defining all of its base objects (window, display, font,
etc.) as CLOS classes and defining all of its functions as generics. Maybe the
"all"'s should be "most"'s, but you get the idea. Without having actually gone
through the whole exercise, I presume that this could be done without change to
any of the function/type names or lambda lists. What do people see as the pro's
and con's of this?
BTW: This is sorta what CLUE does, except only window is (re)defined as a class
and none of of the CLX functions are made generic. In terms of changes to
off-the-shelf CLX, this was the least we could do, so that's what we did.
Also: this kind of "CLOS-ified" CLX has little (if anything) to do with the issue of
"What is the best X toolkit interface for Lisp."
∂06-Oct-88 1207 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:06:53 PDT
Received: from fafnir.think.com by Think.COM; Thu, 6 Oct 88 14:19:33 EDT
Received: from Think.COM by fafnir.think.com; Thu, 6 Oct 88 15:03:53 EDT
Return-Path: <MMcM@stony-brook.scrc.symbolics.com>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by Think.COM; Thu, 6 Oct 88 14:08:17 EDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471918; Thu 6-Oct-88 14:53:04 EDT
Date: Thu, 6 Oct 88 14:52 EDT
From: Mike McMahon <MMcM@stony-brook.scrc.symbolics.com>
Subject: Re: Needed: Info on LISP X based toolkits
To: lanning.pa@xerox.com
Cc: cl-windows@Think.COM, CommonLoops.pa@xerox.com
In-Reply-To: <881005-195006-2101@Xerox>
Message-Id: <19881006185258.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: 5 Oct 88 19:50 PDT
From: lanning.pa@xerox.com
The history of o-o programming and window environments are closely coupled.
With lisp we can do much more that duplicate some other conception of a UI
toolkit. But this will take time and effort. CLOS is a new and unique
language; it is elegant, powerful, efficient (well, maybe), and fun. We
have not had enough experience to understand what the "correct" style of
programming in CLOS is, or know how it will change the way we think about
programming. What is needed is not a premature UI toolkit standard based
on some impoverished language's notion of programming, but a long-term
effort by a large community to try to understand what CLOS really is, what
it is really good for, and what it says about the ways to construct such a
system.
I wonder how the word "standard" crept into your discourse. Or rather,
why you think the existence of one standard precludes all others. The
beauty of a reasonable, low-level standard like X and its direct CLX
analogue is that you can have platform hardware independence and
peaceful coexistence of a multitude of toolkits, or standards if you
prefer. Whoever told you that you had to program your user interfaces
in CLUE lied to you.
CLUE gives a reasonably straightforward implementation of X toolkit
intrinsics for application writers who are familiar with those to use
today. This is valuable while other ideas are worked out.
In my opinion, CLOS is not new and unique, although it shows
considerably more rigor and maturity than its predecessors. It will
indeed be interesting to see how its application within a larger
community of programmers develops into an accepted (correct) style.
From my experience with the use of similar LISP based object systems for
UIMS construction, I have come to believe that the use of object
orientation to implement widget operations or window dressing is
considerably less profound than some of the higher level generic
behaviors.
∂06-Oct-88 1223 CL-Windows-mailer Re: CLX and OOP
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:23:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 12:16:41 PDT
Date: 6 Oct 88 12:08 PDT
From: fischer.pa@Xerox.COM
Subject: Re: CLX and OOP
In-reply-to: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>'s message of Thu, 6
Oct 88 13:08:32 CDT
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: Robert Scheifler <RWS@zermatt.lcs.mit.edu>,
harris%hplwhh@hplabs.hp.com, lanning.pa@Xerox.COM,
cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM,
bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com
Message-ID: <881006-121641-1160@Xerox>
I suspect some of this will become moot once full U/I toolkits are released
in C, since there's more value to their use than a very general low level
interface like CLX or XLib.
To cast it into Stan's metaphor, those are the flowers most of us are
likely to find attractive.
Usually low level design issues are driven by users of the design. Right
now, I think there's only a very small community of CLUE/CLX users. There
are likely to be much larger communities using and driving the design of
forthcoming C based U/I toolkits. Ideally we should work *with* them.
Perhaps we're getting mired in low level interfaces when higher level ones
would be more appropriate to consider for the near term? "Advance work"
for the next generation of toolkit interfaces.
(ron)
∂06-Oct-88 1705 CL-Windows-mailer Re: CLUE and 1K Primrose Path
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:05:08 PDT
Received: by ti.com id AA21656; Thu, 6 Oct 88 19:03:53 CDT
Received: from dsg by tilde id AA29898; Thu, 6 Oct 88 18:52:41 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 18:52:14 CDT
Message-Id: <2801174002-7454620@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 6 Oct 88 18:53:22 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: CLUE and 1K Primrose Path
In-Reply-To: Msg of 5 Oct 88 19:50 PDT from lanning.pa@Xerox.COM
> There is one possible reason for basing CLUE on the X-Toolkit: if there
> were a way of importing C code from the toolkit in a way that made it
> follow the CLUE protocol exactly.
It's time to clarify the relationship between CLUE and Xt, because the above has
never been a goal (though I'll admit -- given enough time and enough money and
enough entrepreneurial hi-de-ho, it might be possible to create a nifty thing
like an automatic Xt-to-CLUE translator).
CLUE is modelled after Xt because Xt has a pretty good model. This, of course,
is apart from any considerations of programming language whatsoever. Some
salient aspects of the model shared by CLUE and Xt:
* Consistent with ideas about UIMS (Seeheim model, shared object model)
that make sense and are beginning to become accepted (emphasis on
"beginning", still no lack of controversy here):
- distinction between semantic components ("application" or
"callbacks") and syntactico-lexical components ("user
interface")
- encapsulation of input-output techniques
- direct manipulation (ergo object-oriented) control
- multi-threaded dialogs
* Geometry management: negotiating geometry among objects up and down
the window composition hierarchy. Support for implementing arbitrary
g.mgmt. policies.
* Resources: support for negotiating programmer vs. user preferences for
certain UI values. Code-less UI programming.
* Support for dynamic binding of events with UI actions (aka "event
translation").
* Timer event sources for driving animations
* Tight integration with the underlying X client interface.
Widgets/contacts are a subclass of windows.
At the surface, in their implementations of this model, CLUE and Xt begin to
diverge. It's not even accurate to call CLUE a "Lisp binding for Xt". The
intent is that CLUE will continue to exploit the advantages offered by CL/CLOS
to maximum benefit.
Reasonable humanoids may disagree about the desirability of the CLUE/Xt model or
other models. Indeed, this should be the focus for further discussion.
∂06-Oct-88 1901 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:01:26 PDT
Received: from fafnir.think.com by Think.COM; Thu, 6 Oct 88 21:13:20 EDT
Received: from Think.COM by fafnir.think.com; Thu, 6 Oct 88 21:57:59 EDT
Return-Path: <mthome@vax.bbn.com>
Received: from VAX.BBN.COM by Think.COM; Thu, 6 Oct 88 21:12:57 EDT
Message-Id: <8810070112.AA01464@Think.COM>
To: Mike McMahon <MMcM@scrc-stony-brook.arpa>
Cc: lanning.pa@xerox.com, cl-windows@Think.COM, CommonLoops.pa@xerox.com
Subject: Re: Needed: Info on LISP X based toolkits
In-Reply-To: Your message of Thu, 06 Oct 88 14:52:00 -0400.
<19881006185258.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: Thu, 06 Oct 88 21:49:08 -0400
From: Mike Thome <mthome@vax.bbn.com>
"I wonder how the word "standard" crept into your
discourse. Or rather, why you think the existence of one
standard precludes all others. The beauty of a reasonable,
low-level standard like X and its direct CLX analogue is that you
can have platform hardware independence and peaceful coexistence
of a multitude of toolkits, or standards if you prefer."
Wazzat?!? Obviously you are using some definition of "standard" I have
been previously unaware of... The issue at hand (I thought) is to work
towards an OO-{window,user-interface}-{system,toolkit,"standard"} that we
could all more-or-less agree is sortof right enough to actually use so
that we can all write portable user interfaces. If X/clx/clue/whatever is to
be one of MANY (key word here) possible platforms to build a REAL
standard user interface package on, then it is the wrong level to be
arguing at.
∂06-Oct-88 1907 CL-Windows-mailer Re: "window virtual machine"
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:07:32 PDT
Received: by ti.com id AA22390; Thu, 6 Oct 88 21:06:14 CDT
Received: from dsg by tilde id AA00834; Thu, 6 Oct 88 19:50:39 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 19:50:12 CDT
Message-Id: <2801177481-7663601@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 6 Oct 88 19:51:21 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: "window virtual machine"
In-Reply-To: Msg of Thu, 06 Oct 88 08:12:14 PDT from kempf@Sun.COM
> It seems as if a "window virtual machine" combining Level 2 & 3
> insulating application developers from the underlying host window systems
> could make window based applications more portable.
Just to keep the conversation lively, let me say that I consider such an
approach to be of questionable usefulness in defining Common Lisp standards.
The biggest problem is that the "window virtual machine" is perforce the "least
common denominator". The "common denominator" approach will find it hard to
support a broad variety of UI styles because of the lack of commonality in input
behavior. The set of possible input events (enter/leave window, exposure, focus
change, button down/up, etc.) has a huge impact on possible UI styles. This is
particularly painful when you consider that there exists a system rich in its
support for modern user interface programming which is already well on its way
toward standardization --- ladies and gentlemen, the X Window System.
The "common denominator" represents portability at a great sacrifice in
functionality with no economic benefit! For portability, the industry will soon
consolidate around one window system in each market anyway, and the impulse for
this standardization is outside the control of the Lisp community. And, with
the advent of OSF, there is even the breath of a hope that X will be a bridge
between the PC and workstation markets.
∂06-Oct-88 1909 CL-Windows-mailer Re: LISP X based toolkits
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:08:51 PDT
Received: by ti.com id AA22384; Thu, 6 Oct 88 21:06:07 CDT
Received: from dsg by tilde id AA00678; Thu, 6 Oct 88 19:37:40 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 19:37:13 CDT
Message-Id: <2801176696-7616461@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 6 Oct 88 19:38:16 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: LISP X based toolkits
In-Reply-To: Msg of Thu, 06 Oct 88 00:15:45 PDT from Warren Harris <harris%hplwhh@HPLABS.HP.COM>
> Adopting a full level (3)
> would pretty much leave (2) obsolete, and since level (3) would then have
> to be at least as powerful as (2), we would consequently be programming to
> just a different version of (2). This argues for the (2.5) (CLUE)
> approach.
Bingo. Exactly our rationale.
> I'm not saying the concept of a Common Lisp User
> Environment should be eliminated, but we should rethink what we mean by
> supporting various levels of a window system. I think this means providing
> a set of classes which understand both the X server and the necessities of
> CL (such as streams), and a means of extending these classes when
> *necessary*.
CLUE's interactive-stream contact is a stab at this. Here, the idea is that there
exists a *special* kind of window which can act just like a CL-standard char
stream, as an arg to read, write, etc. But not every window is a stream. From
time to time, I seem to hear the notion that all window are streams, that
"stream" is the all-encompassing metaphor. But this has always baffled me.
> For one, the degree
> to which CLUE is object-oriented is completely ad hoc...
Absolutely correct.
> (Was this in the name of efficiency or what?)
No. Merely a practical matter of minimizing the "bastardization" of off-the-shelf
CLX. A matter which I'm certainly willing to reconsider.
> Finally, the notion of callbacks seems more like a throwback to C to me.
> Perhaps this is what Lanning is alluding to in his comments about the
> XToolKit. Why aren't these callbacks generic functions which can be
> overridden or inherited by subclasses of the class for which they're
> defined? That would seem cleaner and more straight forward to me.
The idea is that a callback is instance-specific behavior, not class behavior.
That is, every instance of a given class of UI objects has a unique set of
application semantics, which is represented by its callbacks. Further, the
application semantics of a contact instance is defined by the application
programmer and is *unknown* to the contact programmer who defines the contact
class behavior.
You can also imagine other ways of packaging callbacks. I suppose that in CLUE
we opted for maximum flexibility because we weren't willing to claim that we
knew the "right" way to structure the callback interface. For example,
sometimes a callback communicates with the application, and sometimes it
communicates with some other object in a structured UI. Sometimes, the
application wants to know which contact is reporting; sometimes it doesn't care.
Sometimes the contact knows all the data to return; sometimes the application
wants to attach extra data. Sometimes the application wants to define semantics
for a contact action; sometimes the application finds it convenient to ignore
the action. Sometimes the application consists of objects and callbacks will
invoke their methods; but sometimes not. Sometimes you're building up both the
UI and application together; sometimes you're slapping a new UI on an existing
set of application functions. Etc.
One rightful objection to the way CLUE works is that invoking callbacks involves
a look-up that is a lot like method dispatch, so why does it have to be
different? Another approach has recently been pointed out to me. Instead of
looking up a function associated with a 'callback-name, the contact calls the
generic function 'callback-name. The application programmer defines a
instance-specific method for 'callback-name by using an (eql <instance>)
specializer. The method would be created dynamically by using something like
(make-instance 'standard-method ... :function #'application-function-closure
...) and add-method. Why didn't we do this? It didn't occur to us until now! Hey,
10-4 on that CLOS learning curve. Anyway, I'm looking into this, and I'd
appreciate any advice on its pro's and con's.
> I'm sorry if the flames are hot.
No problem. I like the fire, not the cold.
∂07-Oct-88 0743 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 07:40:26 PDT
Received: from fafnir.think.com by Think.COM; Fri, 7 Oct 88 10:40:32 EDT
Received: from Think.COM by fafnir.think.com; Fri, 7 Oct 88 10:37:28 EDT
Return-Path: <mas@jupiter.risc.com>
Received: from risc.com by Think.COM; Fri, 7 Oct 88 10:40:16 EDT
Received: from planets.risc.com (jupiter.risc.com) by risc.com (4.0/SMI-DDN)
id AA08672; Fri, 7 Oct 88 07:37:01 PDT
Received: from saturn.planets.risc.com by planets.risc.com (3.2/SMI-3.2)
id AA11712; Fri, 7 Oct 88 07:34:58 PDT
Message-Id: <8810071434.AA11712@planets.risc.com>
Date: Fri, 7 Oct 88 07:35:12 PDT
From: mas@jupiter.risc.com
To: mthome@vax.bbn.com
Cc: MMcM@scrc-stony-brook.arpa, lanning.pa@xerox.com, cl-windows@Think.COM,
CommonLoops.pa@xerox.com
In-Reply-To: Mike Thome's message of Thu, 06 Oct 88 21:49:08 -0400 <881006-190105-1952@Xerox>
Subject: Needed: Info on LISP X based toolkits
∂07-Oct-88 0824 CL-Windows-mailer Re: CLUE and CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:24:44 PDT
Received: by ti.com id AA27176; Fri, 7 Oct 88 10:19:23 CDT
Received: from SI by tilde id AA16259; Fri, 7 Oct 88 10:12:54 CDT
Message-Id: <2801229162-9141906@SI>
Sender: OREN@SI.csc.ti.com
Date: Fri, 7 Oct 88 10:12:42 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, harris%hplwhh@HPLABS.HP.COM
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLUE and CLX
In-Reply-To: Msg of Thu, 6 Oct 88 09:43 EDT from Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
CLX programmers actually get handed these ids in
event-handler routines.
Yes, there were efficiency arguments here, perhaps inconsequential ones.
They don't tell you what to do with them thought
(like how to lookup the associated xlib:window object).
The CLX doc does tell you to use make-window to perform this mapping.
Just to set the record straight, CLX does NOT use resource ID's in
event-handler routines. Event handlers get passed objects, which are
even interned in a hash table to reduce consing. The alpha version of
CLX passed resource ID's, but it was changed in Sept. 87 to pass objects
(structures). CLX does not export make-window, because there's never a
need to use it. It looks like the documentation needs cleaning up.
∂07-Oct-88 0833 CL-Windows-mailer Re: CLX resource-ids
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:33:27 PDT
Received: by expo.lcs.mit.edu; Fri, 7 Oct 88 11:31:44 EDT
Date: Fri, 7 Oct 88 11:31 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: Re: CLX resource-ids
To: cl-windows@sail.stanford.edu
In-Reply-To: <2801229162-9141906@SI>
Message-Id: <19881007153153.1.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 7 Oct 88 10:12:42 CDT
From: LaMott Oren <Oren@Home.csc.ti.com>
Just to set the record straight, CLX does NOT use resource ID's in
event-handler routines.
Blush. LaMott, is of course correct. Sorry for the confusion.
∂07-Oct-88 1448 CL-Windows-mailer Needed: Info on LISP X based toolkits
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 14:48:10 PDT
Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Fri 7 Oct 88 16:46:20-CDT
Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56)
id AA23633; Fri, 7 Oct 88 16:46:08 CDT
Date: Fri, 7 Oct 88 16:46:04 CDT
From: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Message-Id: <8810072146.AA05549@perseus.sw.mcc.com>
Received: by perseus.sw.mcc.com (3.2/STP1.14)
id AA05549; Fri, 7 Oct 88 16:46:04 CDT
To: lanning.pa@Xerox.COM, cl-windows@sail.stanford.edu
Subject: Needed: Info on LISP X based toolkits
In the spirit of Stan's posting, I'd like to toss in my two bits
worth. First I want to applaud the MIT X Consortium (CLX) and TI
(CLUE) for making their systems available to all of us to examine and
use. Even though these are good designs that do many things well,
there are issues that are not well addressed in those designs. I base
my comments on my imperfect understanding of CLX, CLUE, the
Schlumberger Generic Window System, several years experience with the
lisp machine window system, and on the design of a portable CLOS based
window system.
Here at STP/MCC we have written an object oriented window system
client interface in CLOS. We have a reasonable object oriented
toolkit including menus, buttons, choicers, gauges, sliders,
scrollbars, composed windows, a powerful grapher, and an interface to
a multi-window Gnu emacs server that makes emacs appear as an embedded
editor to common lisp applications. The DELI Window System, DWS, is
part of an application prototyping platform developed for internal
use. This is all in an early alpha stage (and will hopefully
eventually be available from one of our shareholders or MCC).
I believe that some of the considerations that influenced our design
are of general interest in the consideration of a portable standard
common lisp window interface. I will try to summarize these here
(colored by my own biased recollections, and the comments of others at
the CLOS workshop ...). Hopefully some of these will provide good
fodder for discussion.
1. The interface should not depend on a particular window system
protocol. Just as file streams are independent of the network protocol
(nfs, nfile, qfile, ...) the same portability is desirable in a window
system interface. X is wonderful because it will be available on so
many different types of hardware; however I hope that we have even
better protocols in the near future. For example: X is bit mapped
oriented. I expect that before long, powerful display list oriented
graphics capabilities, like those found on the Silicon Graphics IRIS,
will be standard equipment on many workstations. Protocols like NeWS
or Display Postscript will allow applications to take much better
advantage of this hardware.
2. The interface can be made portable by defining an internal window
system independent layer which can be used to retarget the interface
to multiple window systems. This layer should not be a greatest
common denominator, since this approach leads either to an interface
tuned to a particular target or one that performs poorly for all
target window systems. The interface should be designed at a high
enough semantic level so that "intent" is expressed rather than
"procedure" for the most common user interface idioms.
For example concepts such as coordinate transforms, object and region
selection, and object dragging could be supported by the interface.
This means that more work will be required to implement the interface
for "dumber" window servers, however it will be easy to exploit the
capabilities of more sophisticated displays. For example object
dragging could be simulated by XOR redrawing of a bounding box on a
low performance display, bit-blitting a pixrect on a pixel oriented
device, or translating a display list on a display list engine.
The DWS uses a Window System Independent Interface, WSII, that is at a
roughly intermediate level between the X10 and NeWS protocols. The
WSII was originally written for X10R4 and has been retargetted to NeWS
and the X11 (using CLX!) protocols.
Perhaps the ideas behind the CLOS Meta Class protocol can be applied
to produce a more flexible window system interface standard.
3. Although the window system interface on which application toolkits
are built should definitely be object oriented, there is no strong
need for the WSII layer or the specific protocol drivers (CLX) to be
object oriented since they are not exposed to the applications. We
want these to be the fastest way from lisp to the window server.
4. The availability of network window servers requires new "rules of
the road" for cooperative network window system use by applications.
The window system interface should provide support for "network
friendly" applications which do not make assumptions about the display
device, the window manager, the relationship of the hardware executing
the application to that displaying the application, or what other
applications may be trying to share the display space at the same
time. For example "display grabbing" beyond the scope of windows
owned by the application should be avoided.
It should be possible to build "meta applications" that are composed
of several individual applications running in different hardware
environments. These meta applications could be controlled from a
single display terminal and their heterogeneous composition invisible
to the user.
5. Ideally the "look and feel" of the application would defer to that
selected by the user on his workstation display. The ability of many
X applications to run under many different tiled and overlapped window
manager illustrates the direction we should take. The window system
interface should be prepared to provide window management functionality
where none exists, but should gracefully defer to window defaults and
management present on the selected window server.
6. In CLOS Common Lisp has the most powerful object oriented
capability of any language today. A standard window system interface
should provide a standard interface for sub-class specialization as
well as the normal standard instance interface. The sub-class
specialization interface should allow toolkit and application
developers make full use of CLOS capabilities such as multiple
inheritance and specialized meta classes. This additional interface
will allow for much greater leverage in the reuse and customization of
classes and methods in application toolkits without compromising
portability.
Well I've probably run on enough for today. DWS only goes a small way
toward meeting these goals - I'd love to be able to buy a vendor
supported window interface that met most of them (and the important
stuff I've forgotten or don't know yet) in a year or so. I am curious
how my priorities rank with those of others; so I hope we keep this
discussion rolling.
;rob
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp
∂08-Oct-88 1320 CL-Windows-mailer Re: portable CLOS window system
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:20:20 PDT
Received: by ti.com id AA07304; Sat, 8 Oct 88 15:18:50 CDT
Received: from dsg by tilde id AA15121; Sat, 8 Oct 88 15:06:16 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Sat, 8 Oct 88 15:05:47 CDT
Message-Id: <2801333212-505128@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Sat, 8 Oct 88 15:06:52 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: portable CLOS window system
In-Reply-To: Msg of Fri, 7 Oct 88 16:46:04 CDT from Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Rob, can you clarify your characterization of the portable CLOS window system?
Below, I've tried to show the various interface layers that you mentioned. What
exactly do you see as the responsibilities of each layer? In general, what sort
of data goes across each interface? In this picture, what exactly is it that we
should refer to as "the window system"?
Hi Application
. ↑
. |
. V
. Application toolkit
. ↑
. |
. V
. Window system interface
. ↑ ↑
. | |
. V Portable
. Window system-independent interface ...........................
. ↑ Implementation-dependent
. | |
. V V
Lo Base protocol
Consider graphics output and handling specific input events. Would these appear
in the WSII? If so, how will the greatest-common-denominator effect be avoided?
If not, how will an abstract "intent" for these be specified?
Look+feel control: Should this be possible across the standard window system
interface? Or is look+feel an implementation-dependent aspect?
BTW, the X Consortium is developing a standard for "core components". This
would standardize a *functional* programming interface to certain common UI
objects (e.g. buttons, menus, etc.) that is explictly look+feel-free. The
intent is that this common core interface could be implemented to exhibit "any"
look+feel. Hopefully, the core standard spec will also be language-independent.
[I am not alone among the non-C people in the working group, although sometimes
I worry.] Perhaps the core could even be toolkit-independent. [I am alone among
the non-Xt people and I definitely worry!] Rob, where would something like this
fit into your picture?
∂08-Oct-88 1327 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:26:53 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473257; Sat 8-Oct-88 16:24:39 EDT
Date: Thu, 6 Oct 88 16:26 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Needed: Info on LISP X based toolkits
To: Warren Harris <harris%hplwhh@hplabs.hp.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <8041.592125345@hplwhh>
Message-ID: <19881006202630.1.MMCM@OWL.SCRC.Symbolics.COM>
It seems that I may not have successfully conveyed my position
originally. So, I am somewhat unsure what it is that you then agreed
with and have now changed you mind on. Of course, I will not rule out
the possibility that we disagree.
The situation with :EXPOSE is meant merely as an example of an area in
which a protocol must be careful about its specification. Certainly, it
is not an indication of the impossibility of the task of an object
oriented window system. Nor is the way in which the situation was (or
was not) rectified in the LISP machine window systems directly relevant.
The suggestion with exactly that these experiences be used as a basis
for improvement.
My point concerning cursor attachment mixins was this: I do not see a
valid protocol definition under which this makes sense. Either the line
drawing operation is defined to affect the cursor, or it is not. I
contrast this with an operation to draw some text and move the cursor.
Here, there is a perfectly valid class which moves the cursor to the
left rather than to the right, the notion of text movement being general
in the protocol description. In my opinion, nothing has been gained by
redefining the draw-line operation, except saving the bother of coming
up with a different name for the new operation.
My motivation for not using CLOS in CLX is more fundamental than the
specifics of the cases which you cited. Once again, it is a matter of
having a clear protocol. The semantics of the X protocol, and hence of
CLX, are exactly determined by the server. There is no flexibility
there. Hence, a dependent specialization that changed those semantics
would destroy the isomorphism. For this reason, I recommended
structures and normal functions. Of course, this does not mean that one
could not use instances for the objects and generic functions for the
operations. Nor would doing so immediately and necessarily result in
disaster. However, in a properly constructed higher level toolkit, the
instances would only be extended and the operations encapsulated. In
other words, the result would be functionally identical to having the
lower level structures as instance variables.
I do not see it as a problem that your higher level toolkit had to
define a lot of generic functions that do just a single server
operation. In my opinion, to merge the two would have been a false
parsimony. It hides the additional semantics which you (presumably)
attached to the higher level operations. If in fact, your operations
are identical to those of the server because they make sense even at the
next higher level of abstraction, then perhaps you should indeed lobby
the authors of CLX to migrate to CLOS. It is an implementation tradeoff.
From hard experience, I know that object-oriented programming, or
information hiding in general, should not mean that the left hand does
not know what the right is doing.
∂08-Oct-88 1342 CL-Windows-mailer Re: "window virtual machine"
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:42:32 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473268; Sat 8-Oct-88 16:40:40 EDT
Date: Fri, 7 Oct 88 16:42 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: "window virtual machine"
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2801177481-7663601@Sierra>
Message-ID: <19881007204213.3.MMCM@OWL.SCRC.Symbolics.COM>
As I see it, the challenge is to come up with a means of specification
for a user interface that is powerful enough to be used by real
applications, and at the same time flexible enough to adapt to different
user interface systems and user preferences.
I agree that it is nearly impossible to do this at the low level of a
window virtual machine. That is not to say that there is no higher
level commonality.
In the end, is it not these more abstract levels that the application
programmer wants to deal with anyway? Even if the the utopia (pardon)
of a single user interface came about, would it not be worthwhile to
have done it that way anyhow?
∂08-Oct-88 1344 CL-Windows-mailer Re: Needed: Info on LISP X based toolkits
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:44:17 PDT
Received: from fafnir.think.com by Think.COM; Sat, 8 Oct 88 16:41:39 EDT
Received: from Think.COM by fafnir.think.com; Sat, 8 Oct 88 16:41:15 EDT
Return-Path: <MMcM@stony-brook.scrc.symbolics.com>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by Think.COM; Sat, 8 Oct 88 16:34:09 EDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473263; Sat 8-Oct-88 16:33:46 EDT
Date: Fri, 7 Oct 88 16:35 EDT
From: Mike McMahon <MMcM@stony-brook.scrc.symbolics.com>
Subject: Re: Needed: Info on LISP X based toolkits
To: Mike Thome <mthome@vax.bbn.com>
Cc: lanning.pa@xerox.com, cl-windows@Think.COM
In-Reply-To: <8810070112.AA01464@Think.COM>
Message-Id: <19881007203520.2.MMCM@OWL.SCRC.Symbolics.COM>
Date: Thu, 06 Oct 88 21:49:08 -0400
From: Mike Thome <mthome@vax.bbn.com>
"I wonder how the word "standard" crept into your
discourse. Or rather, why you think the existence of one
standard precludes all others. The beauty of a reasonable,
low-level standard like X and its direct CLX analogue is that you
can have platform hardware independence and peaceful coexistence
of a multitude of toolkits, or standards if you prefer."
Wazzat?!? Obviously you are using some definition of "standard" I have
been previously unaware of...
Both C and LISP are ANSI standard languages. There are even a lot of
machines which can be programmed using either one. Standard means that
we agree on how it works, not that we agree that everything works that
way.
The issue at hand (I thought) is to work
towards an OO-{window,user-interface}-{system,toolkit,"standard"} that we
could all more-or-less agree is sortof right enough to actually use so
that we can all write portable user interfaces.
Portability comes from the server level. If the next level up, and the
level and above that, and so on, are all portable, then the whole user
interface is indeed portable. I think consistent or some other
constraint is what you are getting at, not portable. Or rather, you
want portability of the users, not the user interface itself.
If X/clx/clue/whatever is to
be one of MANY (key word here) possible platforms to build a REAL
standard user interface package on, then it is the wrong level to be
arguing at.
Different applications will make different tradeoffs between control and
portability/consistency. For that reason, care is required at all
levels.
∂08-Oct-88 1428 CL-Windows-mailer "...Both C and LISP are ANSI standard languages."
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 14:28:10 PDT
Received: from fafnir.think.com by Think.COM; Sat, 8 Oct 88 17:25:14 EDT
Received: from Think.COM by fafnir.think.com; Sat, 8 Oct 88 17:25:04 EDT
Return-Path: <masinter.pa@xerox.com>
Received: from Xerox.COM by Think.COM; Sat, 8 Oct 88 17:25:00 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 14:25:55 PDT
Date: 8 Oct 88 14:25 PDT
From: masinter.pa@xerox.com
Subject: "...Both C and LISP are ANSI standard languages."
In-Reply-To: Mike McMahon <MMcM@stony-brook.scrc.symbolics.com>'s message
of Fri, 7 Oct 88 16:35 EDT
To: Mike McMahon <MMcM@stony-brook.scrc.symbolics.com>
Cc: cl-windows@Think.COM
Message-Id: <881008-142555-2230@Xerox>
While we're slugging away to create an ANSI Standard for Common Lisp, it is
a time-consuming process. We're hoping that there will be draft next year;
after a draft is published, there is a period of public review before it
becomes an ANSI standard. I believe the process for C is further along, but
then, C is a much simpler language; there is no ANSI standard C library,
for example.
There is also a separate group trying to create an ISO standard for ISLISP.
(Not for "Lisp", by the way.)
The "windows" subcommittee of X3J13 has been dormant -- apparently no one
was willing to invest any energy into sorting out the similarities and
differences among the competing systems.
∂11-Oct-88 0302 CL-Windows-mailer LISP X based toolkits
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 11 Oct 88 03:02:23 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02478; 11 Oct 88 6:00 EDT
Received: from etl.jp by RELAY.CS.NET id ah02232; 11 Oct 88 5:45 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA04354; Tue, 11 Oct 88 17:25:07 JST
Date: Tue, 11 Oct 88 17:25:07 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Cc: Kimbrough@dsg.csc.ti.com
In-Reply-To: Kerry Kimbrough's message of Thu, 6 Oct 88 19:38:16 CDT
Subject: LISP X based toolkits
>Sender: KK@sierra.csc.ti.com
>Date: Thu, 6 Oct 88 19:38:16 CDT
>From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
>
>One rightful objection to the way CLUE works is that invoking callbacks involves
>a look-up that is a lot like method dispatch, so why does it have to be
>different? Another approach has recently been pointed out to me. Instead of
>looking up a function associated with a 'callback-name, the contact calls the
>generic function 'callback-name. The application programmer defines a
>instance-specific method for 'callback-name by using an (eql <instance>)
>specializer. The method would be created dynamically by using something like
>(make-instance 'standard-method ... :function #'application-function-closure
>...) and add-method. Why didn't we do this? It didn't occur to us until now! Hey,
>10-4 on that CLOS learning curve. Anyway, I'm looking into this, and I'd
>appreciate any advice on its pro's and con's.
But it seems to me that it is too heavy in most implementations to add
or remove methods at run time because of re-hashing of a method table
or similar things in order to speed up of generic-function callings,
Another approach is adding methods using WITH-ADDED-METHODS, but they
are only available lexically.
Haruyuki Kawabe
Knowledge System Department
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂11-Oct-88 0302 CL-Windows-mailer LISP X based toolkits
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 11 Oct 88 03:02:36 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab02477; 11 Oct 88 6:00 EDT
Received: from etl.jp by RELAY.CS.NET id ag02232; 11 Oct 88 5:44 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA04315; Tue, 11 Oct 88 17:24:17 JST
Date: Tue, 11 Oct 88 17:24:17 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-windows@SAIL.STANFORD.EDU
Cc: Kimbrough@dsg.csc.ti.com
In-Reply-To: Kerry Kimbrough's message of Thu, 6 Oct 88 19:38:16 CDT
Subject: LISP X based toolkits
>Sender: KK@sierra.csc.ti.com
>Date: Thu, 6 Oct 88 19:38:16 CDT
>From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
>
>One rightful objection to the way CLUE works is that invoking callbacks involves
>a look-up that is a lot like method dispatch, so why does it have to be
>different? Another approach has recently been pointed out to me. Instead of
>looking up a function associated with a 'callback-name, the contact calls the
>generic function 'callback-name. The application programmer defines a
>instance-specific method for 'callback-name by using an (eql <instance>)
>specializer. The method would be created dynamically by using something like
>(make-instance 'standard-method ... :function #'application-function-closure
>...) and add-method. Why didn't we do this? It didn't occur to us until now! Hey,
>10-4 on that CLOS learning curve. Anyway, I'm looking into this, and I'd
>appreciate any advice on its pro's and con's.
But it seems to me that it is too heavyin most implementations to add or remove methods at
run time because of re-hashing of a method table or
similar things in order to speed up of generic-function callings,
Another approach is adding methods using WITH-ADDED-METHODS (or
GENERIC-FLET), but they are only available lexically.
∂11-Oct-88 0632 CL-Windows-mailer LISP X based toolkits
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 11 Oct 88 06:32:21 PDT
Received: from CHOMOLUNGMA.ACA.MCC.COM (CHOMOLUNGMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Tue 11 Oct 88 08:30:12-CDT
Date: Tue, 11 Oct 88 08:29 CDT
From: William D. Gooch <ai.gooch@MCC.COM>
Subject: LISP X based toolkits
To: kawabe@etl.jp
cc: cl-windows@SAIL.STANFORD.EDU, Kimbrough@dsg.csc.ti.com
In-Reply-To: The message of 11 Oct 88 03:25 CDT from Haruyuki Kawabe <kawabe@etl.jp>
Message-ID: <19881011132939.9.GOOCH@CHOMOLUNGMA.ACA.MCC.COM>
Date: Tue, 11 Oct 88 17:25:07 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
But it seems to me that it is too heavy in most implementations to add
or remove methods at run time because of re-hashing of a method table
or similar things in order to speed up of generic-function callings,....
Oh, come now - surely in this case the gain is worth the pain. It seems
to me that it's absolutely essential to have this kind of flexibility as
a CLUE user, and I would gladly pay the price (you can certainly choose
not to!).
∂11-Oct-88 0726 CL-Windows-mailer CLX, CLUE and LISP/X Toolkits...
Received: from cheddar.cs.wisc.edu by SAIL.Stanford.EDU with TCP; 11 Oct 88 07:25:57 PDT
Message-Id: <8810111423.AA03322@cheddar.cs.wisc.edu>
Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Tue, 11 Oct 88 09:23:18 CDT
From: "David C. Martin" <dcmartin@cs.wisc.edu>
Organization: University of Wisconsin - Madison
Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin
Phone: 608/262-6624 (O)
To: cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Fri, 7 Oct 88 16:42 EDT
<19881007204213.3.MMCM@OWL.SCRC.Symbolics.COM>
Subject: CLX, CLUE and LISP/X Toolkits...
Date: Tue, 11 Oct 88 09:23:15 -0500
Sender: dcmartin@cs.wisc.edu
I have been reading the passing mail, but haven't had time to comment until
now.
I find most of this discussion revolving around two subjects:
1) What should a LISP window system be?
2) How can X, CLX, CLUE, NeWS or ??? be a means to providing a solution to 1.
I implemented an X10 interface for Common LISP called XCL. This is a foreign
function interface to the C Xlib functions and required mucho hacking to
provide the semantics which I wanted in a LISP environment.
On top of XCL I began implementing XCLOS, which is an object-oriented version
of XCL, but with a difference from the CLX/CLUE path in that it did not change
the underlying structures or functions of XCL. Granted that certain
modifications were made to XCL in order to support some of the semantics
required by a more complex system (e.g. searching the X event queue).
After the initial implementation of XCLOS numerous problems with speed arose.
Many of these problems had their origins in the speed of PCL, but other were
due to the object-oriented model in general (e.g. making each X event an
object). The overall design of XCLOS was a strict object-oriented system,
and I did not make any effort to optimize certain characteristics at the top
level (e.g. event processing).
To solve the event processing model, I allowed the XCLOS programmer to utilize
the efficiency of XCL by registering user-defined (and some system defined)
event handling functions to particular event characteristics (much like NeWS
allows any arbitrary PostScript function to be sent to the backend to increase
performance). What I discovered was that I achieved a drop from ~ 80 ms/event
to ~ 20 ms/event for the null event case (i.e. I asked for the event, but at
the time of receipt it was uninteresting and I chose to ignore it). An actual
event scenario for key-pressed input events brought in processing speeds of
42 ms/event when using user-defined optimized event handling, but with every
other aspect being object-oriented (e.g. sending the putc message to the
appropriate window).
Now back to (1) and (2): I don't know what a LISP window system should be; I
also don't know whether X > NeWS or NeWS > X or ??? > X, ??? > NeWS. I do know
that we have X and CLX now and both provide adequate performance across a
variety of hardware.
The preceding information about the XCL/XCLOS system was to show that
performace in an object-oriented system can be achieved if the OO system
allows the user to access the non-OO system in a clean and standard fashion.
In addition, version control for the OO system can provide even greater
optimizations by utilizing compile-time method determination (e.g. on
``frozen'' generic-functions in the PCL/CLOS world) and in-line expansion of
non-OO functions inside OO methods (i.e. to handle the case of putc to a window
which is based on some XCL function). Furthermore, version-control and some
type of optimizer could generate or access optimized routines from the low
level integration methods which connect the OO to the non-OO.
I would like to see some expansion of the semantics of streams in Common LISP
to allow them to be expanded to support windows (e.g. Common Windows), but I
don't think that such support should be object-oriented, only standardized for
CL to allow OO extensions later.
Well, those are my thoughts on this subject.
dcm
∂11-Oct-88 0922 CL-Windows-mailer Re: run-time method definition
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Oct 88 09:22:47 PDT
Received: by ti.com id AA27371; Tue, 11 Oct 88 11:19:32 CDT
Received: from dsg by tilde id AA13554; Tue, 11 Oct 88 11:09:04 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 11 Oct 88 11:10:51 CDT
Message-Id: <2801578249-4548267@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 11 Oct 88 11:10:49 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: "William D. Gooch" <ai.gooch@MCC.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: run-time method definition
In-Reply-To: Msg of Tue, 11 Oct 88 08:29 CDT from William D. Gooch <ai.gooch@MCC.COM>
> Date: Tue, 11 Oct 88 08:29 CDT
> From: William D. Gooch <ai.gooch@MCC.COM>
> Subject: LISP X based toolkits
>
> Date: Tue, 11 Oct 88 17:25:07 JST
> From: Haruyuki Kawabe <kawabe@etl.jp>
>
> But it seems to me that it is too heavy in most implementations to add
> or remove methods at run time because of re-hashing of a method table
> or similar things in order to speed up of generic-function callings,....
>
> It seems
> to me that it's absolutely essential to have this kind of flexibility as
> a CLUE user...
William, can you elaborate on why you see this approach as more flexible and why
this is essential? This is a hot topic in CLUE-land, and we're trying to get to
the bottom of it.
For CLUE, defining callbacks as (eql instance)-specialized methods (instead of
functions looked up in an a-list instance variable) has been seen mainly as an
issue of packaging and of efficiency. Each technique gets the same job done.
Here's how the pro's and con's stack up so far.
Alternatives:
a. A-list: add-callback: add (name function . args) to callbacks
a-list. apply-callback looks up and calls function associated
with name.
b. eql method: (make-instance 'standard-method ... :function
function :lambda-list `((eql ,contact) ...)) creates a callback
associated with a contact instance. (add-method generic-callback
method) adds this method to a generic function. Callback is
invoked by calling generic-callback with contact as specializer
arg.
Pro: Eliminates apply-callback and a-list lookup. Exploits CLOS
method dispatch. Contact programmer can define qualified
methods of callbacks.
Con: Extra complexity: closure required to "package"
application-supplied callback args. Deleting a callback
is harder. Prevents contact and callbacks from being
garbage-collected.
The concern about deleting a callback is that it would involve remove-method,
but there's no find-generic-function, and find-method requires you to recall a
callback's full lambda list.
Another efficiency concern is method dispatch vs. small a-list lookup: which is
likely to be faster?
∂11-Oct-88 1019 CL-Windows-mailer portable CLOS window system
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 11 Oct 88 10:18:52 PDT
Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Tue 11 Oct 88 11:06:22-CDT
Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56)
id AA06327; Tue, 11 Oct 88 11:04:52 CDT
Date: Tue, 11 Oct 88 11:04:50 CDT
From: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Message-Id: <8810111604.AA12030@perseus.sw.mcc.com>
Received: by perseus.sw.mcc.com (3.2/STP1.14)
id AA12030; Tue, 11 Oct 88 11:04:50 CDT
To: Kimbrough@dsg.csc.ti.com
Cc: rcp%sw.MCC.COM@MCC.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: Kerry Kimbrough's message of Sat, 8 Oct 88 15:06:52 CDT <2801333212-505128@Sierra>
Subject: portable CLOS window system
Date: Sat, 8 Oct 88 15:06:52 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: portable CLOS window system
In-Reply-To: Msg of Fri, 7 Oct 88 16:46:04 CDT from Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Rob, can you clarify your characterization of the portable CLOS window system?
Below, I've tried to show the various interface layers that you mentioned. What
exactly do you see as the responsibilities of each layer? In general, what sort
of data goes across each interface? In this picture, what exactly is it that we
should refer to as "the window system"?
Hi Application
. ↑
. |
. V
. Application toolkit
Here is a pass based on our experiences (positive and negative) with
the DELI Window System ...
The Application toolkits provide:
* A consistent look and feel for the elements in the toolkit library.
Note that the WSII (below) should provide an interface to query for
user interface preferences currently in effect for the window server
and display. This could include colors, fonts, mouse interaction
style (ie click-to-select, hold-and-release). This whole area of
window manager / toolkit responsibility and style clash is an
important one to work on.
* Elaborating the functionality of the basic window system gadgets,
while respecting the common protocols established in the window system
layer.
* Providing common low level applications such as editors (text and
figure), graphers, application interface construction tools, ...
. Window system interface
The window system (client) interface corresponds most closely the the
normal concept of a window system. In addition to the primitives of
the WSII, the full window system interface adds an extended event
model, compound windows (window objects that represent collections of
screen windows), buttons, simple menus, viewing transforms, gauges,
sliders, scrollbars ... As much as possible this layer should be look
and feel independent. The emphasis is in two areas:
* Fleshing out the WSII functionality into a more useful programatic
interface. Toolkits could be build directly on the WSII. The window
system layer gives us a chance to include interfaces for common window
idioms built on the WSII which all tookits will want to share
* Defining the basic programming protocols for window system gadgets
that will be elaborated in the toolkits. The visual appearance of
gadgets is primitive and neutral, the emphasis is on working out the
interfaces and protocols for interaction between windows and gadgets.
For example: how a scrollbar communicates with the viewing transform
of a window.
This layer will provide both a programatic interface (to use it as it
is) and a class specialization interface to allow customization and
reuse of the window system interace in the toolkit and applications.
. Window system-independent interface ...........................
The WSII implements the window virtual machine interface as a
collection of primitive window system resource objects and operations.
Graphical drawing contexts, coordinate systems, canvases(primitive
windows), fonts, colors, streams, active regions, window system event
handling, and drawing are all defined here. The WSII has the
responsibility of maintaining consistency between the actual
configuration of windows on the screen and the lisp world knowledge of
those windows. This will require automatic handling of some window
server events (for example resizing and negotiations with a tiled
window manager). This layer should be a subset of the full window
system defined in the layer above. The functions and objects in its
external interface should be specializable. This layer must be ported
to each new window server interface.
. ↑ Implementation-dependent
. | |
. V V
Lo Base protocol
The base protocol interface provides communication with a specific
type of window server. It should provide as efficient an interface as
possible to the basic protocol (ie the X protocol, not xlib, not clx).
The reason for this layer being at a very low level is to avoid
gratuitous differences with the WSII and the need for inefficient
changes in representation. For DWS Jim Peterson and Glenn Downing
wrote NX (ie Native X interface to X10R4) which was mostly automaticly
generated from the X10 network protocol specification and had only a
very thin veneer of functionality above that. Basing this layer on
stream communications to a server makes it easy to port to a new
compiler or new hardware.
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp
∂11-Oct-88 1330 CL-Windows-mailer Re: run-time method definition
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 11 Oct 88 13:29:58 PDT
Received: from CHOMOLUNGMA.ACA.MCC.COM (CHOMOLUNGMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Tue 11 Oct 88 15:28:05-CDT
Date: Tue, 11 Oct 88 15:27 CDT
From: William D. Gooch <ai.gooch@MCC.COM>
Subject: Re: run-time method definition
To: Kimbrough@dsg.csc.ti.com
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2801578249-4548267@Sierra>
Message-ID: <19881011202758.1.GOOCH@CHOMOLUNGMA.ACA.MCC.COM>
Date: Tue, 11 Oct 88 11:10:49 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
William, can you elaborate on why you see this approach as more flexible and why
this is essential? This is a hot topic in CLUE-land, and we're trying to get to
the bottom of it.
I'll be happy to try. I should say first that I may have overstated
the case by using the word "essential" and should probably downgrade
that slightly to "very important."
For CLUE, defining callbacks as (eql instance)-specialized methods (instead of
functions looked up in an a-list instance variable) has been seen mainly as an
issue of packaging and of efficiency. Each technique gets the same job done.
Here's how the pro's and con's stack up so far.
Alternatives:
a. A-list: add-callback: .... apply-callback ....
b. eql method: .... add-method .... generic-callback ....
Pro: Eliminates apply-callback and a-list lookup. Exploits CLOS
method dispatch. Contact programmer can define qualified
methods of callbacks.
This last is the added flexibility I was alluding to. As I understand
it, the programmer has to completely redefine an alist-indexed callback
function in order to change its behavior, whereas a method may simply be
qualified. I see this as an overriding advantage of the method-based
approach.
Con: Extra complexity: closure required to "package"
application-supplied callback args. Deleting a callback
is harder. Prevents contact and callbacks from being
garbage-collected.
The concern about deleting a callback is that it would involve remove-method,
but there's no find-generic-function, and find-method requires you to recall a
callback's full lambda list.
Another efficiency concern is method dispatch vs. small a-list lookup: which is
likely to be faster?
None of these potential problems seem particularly bothersome to me,
although I don't claim to fully understand the issues involved. I think
it would be very unfortunate to limit the robustness of the design just
for the sake of efficiency at this stage. What evidence is there that
the concerns mentioned reflect considerable drawbacks, and that there
are no workable solutions even if they do?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A tangential note which has occurred to me as I was writing this (I hope
someone on the X3J13 committee is listening) -- for the sake of CLUE, it
may be important that there exist a :within method combination (sort of
the inverse of :around). I won't go into detail here, since it's a
whole different discussion, but if the reasoning isn't clear, I can
elaborate under separate cover.
∂12-Oct-88 0322 CL-Windows-mailer run-time method definition
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Oct 88 03:21:54 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa21801; 12 Oct 88 3:01 EDT
Received: from etl.jp by RELAY.CS.NET id aa09518; 12 Oct 88 2:41 EDT
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA28755; Wed, 12 Oct 88 14:11:49 JST
Date: Wed, 12 Oct 88 14:11:49 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: Kimbrough@dsg.csc.ti.com
Cc: ai.gooch@MCC.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: Kerry Kimbrough's message of Tue, 11 Oct 88 11:10:49 CDT <2801578249-4548267@Sierra>
Subject: run-time method definition
>Sender: KK@sierra.csc.ti.com
>Date: Tue, 11 Oct 88 11:10:49 CDT
>From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
>
> > Date: Tue, 11 Oct 88 08:29 CDT
> > From: William D. Gooch <ai.gooch@MCC.COM>
> > Subject: LISP X based toolkits
> >
> > Date: Tue, 11 Oct 88 17:25:07 JST
> > From: Haruyuki Kawabe <kawabe@etl.jp>
> >
> > But it seems to me that it is too heavy in most implementations to add
> > or remove methods at run time because of re-hashing of a method table
> > or similar things in order to speed up of generic-function callings,....
Excuse me, only adding (eql instance)-specialized methods to a generic
function is not so heavy. Please ignore my opinion above.
> b. eql method: (make-instance 'standard-method ... :function
> function :lambda-list `((eql ,contact) ...)) creates a callback
> associated with a contact instance. (add-method generic-callback
> method) adds this method to a generic function. Callback is
> invoked by calling generic-callback with contact as specializer
> arg.
>
> Con: Extra complexity: closure required to "package"
> application-supplied callback args. Deleting a callback
> is harder. Prevents contact and callbacks from being
> garbage-collected.
>
>
>The concern about deleting a callback is that it would involve remove-method,
>but there's no find-generic-function, and find-method requires you to recall a
>callback's full lambda list.
So callback methods should take only one argument which is (contact
(eql instance)) and other application-supplied data are closed using
closures when these methods are created. Then you can easily find your
method. (Generic-function objects could be refer by (FUNCTION
generic-function-name)) Moreover a clousre is stronger and more
convenient than passing application-supplied callback args using
ADD-CALLBACK when they changes frequently.
Haruyuki Kawabe
Knowledge System Department
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂27-Oct-88 1906 CL-Windows-mailer OBJECT-ORIENTED CLX
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 27 Oct 88 19:05:57 PDT
Received: from hplms2.hpl.hp.com by RELAY.CS.NET id aa00745; 27 Oct 88 20:46 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 27 Oct 88 17:35:27 pdt
Received: from loopback by hplwhh.HPL.HP.COM; Thu, 27 Oct 88 17:34:05 pdt
Full-Name: Warren Harris
To: cl-windows@SAIL.STANFORD.EDU
Cc: commonloops.pa@XEROX.COM
Subject: OBJECT-ORIENTED CLX
X-Mailer: mh6.5
Date: Thu, 27 Oct 88 17:34:01 PDT
Message-Id: <3463.594002041@hplwhh>
From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
The following is a very rough outline of how CLX might look if it were
an object-oriented program. We've been kicking this idea around in our lab
for a little while now and felt it was time to get some real feedback on
whether this was a good idea or not. All comments are welcome.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;
;;;; AN OBJECT-ORIENTED CLX
;;;;
;;;; (A ROUGH DRAFT)
;;;;
;;;; Warren Harris, HP Labs
;;;;
#|
This document is an attempt to address some of the issues of combining CLX
with object-oriented programming. It is the desire that this "low level"
interface to X11 will be sufficient to implement higher level extensions
such as those found in CLUE in a convenient and extensible way.
Throughout this document we make use of the CLOS meta-object protocol. In
particular, a new meta-class is defined, X-CLASS, which makes convenient
the specification of objects allocated external to the Lisp process (in the
X server). In this meta-class, a new slot-descriptor is defined,
X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation,
namely :X-SERVER. Specifying :X-SERVER allocation does not reserve space
in the actual CLOS object for the value, but instead defines reader and
writer methods which actually perform the X protocol requests. (There may
be other slot-descriptor declarations necessary in the actual
implementation, such as which position the argument takes in the protocol
request, or how to convert between the Lisp representation and the protocol
representation. For more difficult request functions, explicit DEFMETHOD
forms must be written. However, it is still beneficial to think of these
attributes as "slots", allocated in the X server process.)
One difficulty with the old CLX model is that some objects are created in
the server process simultaneous with their creation in the Lisp process.
This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs. Other objects are
created in the server process some time after their creation in the Lisp
process. This includes DISPLAYs, and FONTs. This object-oriented
version of CLX takes the uniform approach of delaying the creation of all
server allocated objects until the OPEN-OBJECT generic function is called.
This has some distinct advantages:
1. It allows MAKE-INSTANCE and the standard CLOS initialization to
be used to create all CLX objects.
2. It allows the objects' states to be remembered between Lisp
sessions.
This second point is a significant advantage since Lisp images can
typically be stored on disk via some SAVE-WORLD command. Lisp images with
saved CLX objects can then be recreated numerous times. (Note: the way
this works is that while a window is open, all :X-SERVER allocated instance
variable accesses go through the X server. When the window is closed, the
values of these slots as they currently exist in the server are re-cached
in the lisp objects before the server object is actually destroyed. That
way, the next time the window is opened the state is remembered.)
Although this document describes vaporware at this point, it should be
pointed out that all these concepts have been verified in an X10 Lisp
interface developed by HP Labs called "Xenon". (Xenon is not distributable
due to its heavy reliance on HP-CL's foreign function mechanism.)
This document has also left out all the actual CLX function and macros.
The intention is that most of the functions in the existing CLX document
will become generic. They were not included here at the present time due
to lazyness.
|#
;;; X-OBJECT
;;;
;;; This class represents the root of the CLX object hierarchy.
(defclass x-object ()
()
(:metaclass x-class))
;;; EXTERNAL-OBJECT
;;;
;;; These are objects which are allocated in the X server process. They must
;;; be explicitly opened and closed by the Lisp process.
(defclass external-object (x-object)
((xid
:type card32
:allocation :instance)
(display
:type display
:reader display
:allocation :instance))
(:metaclass x-class))
(defgeneric open-object (external-object))
(defgeneric close-object (external-object))
(defgeneric open-p (external-object))
;;; X-PLIST-MIXIN
;;;
;;; These are objects with external X properties. It is an error to
;;; instantiate this class directly.
(defclass x-plist-mixin (x-object)
((x-plist
:type list
:initform nil
:initarg :x-plist
:accessor x-plist
:allocation :x-server))
(:metaclass x-class))
(defgeneric get-x-prop (x-plist-object x-prop-name
&key type (start 0) end delete-p (result-type 'list)
transform)
(declare (type x-plist-mixin x-plist-object)
(type xatom property)
(type (or null xatom) type)
(type array-index start)
(type (or null array-index) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defgeneric set-x-prop (x-plist-object x-prop-name x-prop-value
type format
&key (mode :replace) (start 0) end transform)
(declare (type x-plist-mixin x-plist-object)
(type xatom x-prop-name type)
(type (member 8 16 32) format)
(type sequence x-prop-value)
(type (member :replace :prepend :append) mode)
(type array-index start)
(type (or null array-index) end)
(type (or null (function (t) integer)) transform)))
(defgeneric rem-x-prop (x-plist-object x-prop-name)
(declare (type x-plist-mixin x-plist-object)
(type xatom x-prop-name)))
;;; DRAWABLE
(defclass drawable (x-plist-mixin
external-object)
((parent
:type int16
:initform 0
:initarg :parent
:reader parent
:allocation :x-server)
(outside-left
:type int16
:initform 0
:initarg :outside-left
:accessor outside-left
:allocation :x-server)
(outside-top
:type int16
:initform 0
:initarg :outside-top
:accessor outside-top
:allocation :x-server)
(inside-width
:type card16
:initform 1
:initarg :inside-width
:accessor inside-width
:allocation :x-server)
(inside-height
:type card16
:initform 1
:initarg :inside-height
:accessor inside-height
:allocation :x-server)
(border-width
:type card16
:initform 0
:initarg :border-width
:accessor border-width
:allocation :x-server)
(depth
:type card16
:initform 0
:initarg :depth
:accessor depth
:allocation :x-server))
(:metaclass x-class))
;;; WINDOW
(defclass window (drawable)
((i/o-class
:type (member :copy :input-output :input-only)
:initform :copy
:initarg :i/o-class
:reader i/o-class
:allocation :x-server)
(visual
:type (or (member :copy) visual)
:initform :copy
:initarg :visual
:reader visual
:allocation :x-server)
(background-color
:type (or null (member :none :parent-relative) pixel pixmap)
:initform nil
:initarg :background-color
:accessor background-color
:allocation :x-server)
(border-color
:type (or null (member :copy) pixel pixmap)
:initform nil
:initarg :border-color
:accessor border-color
:allocation :x-server)
(window-gravity
:type (or null win-gravity)
:initform nil
:initarg :window-gravity
:accessor window-gravity
:allocation :x-server)
(bit-gravity
:type (or null bit-gravity)
:initform nil
:initarg :bit-gravity
:accessor bit-gravity
:allocation :x-server)
(backing-store
:type (or null (member :not-useful :when-mapped :always))
:initform nil
:initarg :backing-store
:accessor backing-store
:allocation :x-server)
(backing-planes
:type (or null pixel)
:initform nil
:initarg :backing-planes
:accessor backing-planes
:allocation :x-server)
(backing-color
:type (or null pixel)
:initform nil
:initarg :backing-color
:accessor backing-color
:allocation :x-server)
(save-under
:type (or null (member :on :off))
:initform nil
:initarg :save-under
:accessor save-under
:allocation :x-server)
(event-mask
:type (or null event-mask)
:initform nil
:initarg :event-mask
:accessor event-mask
:allocation :x-server)
(do-not-propagate-mask
:type (or null device-event-mask)
:initform nil
:initarg :do-not-propagate-mask
:accessor do-not-propagate-mask
:allocation :x-server)
(override-redirect
:type (or null (member :on :off))
:initform nil
:initarg :override-redirect
:accessor override-redirect
:allocation :x-server)
(colormap
:type (or null (member :copy) colormap)
:initform nil
:initarg :colormap
:accessor colormap
:allocation :x-server)
(cursor
:type (or null (member :none) cursor)
:initform nil
:initarg :cursor
:accessor cursor
:allocation :x-server)
(colormap-installed-p
:type boolean
:reader colormap-installed-p
:allocation :x-server)
(all-event-masks
:type mask32
:reader all-event-masks
:allocation :x-server)
(map-state
:type (member :unmapped :unviewable :viewable)
:reader map-state
:allocation :x-server))
(:metaclass x-class))
(defgeneric (setf priority) (mode window &optional sibling))
;;; PIXMAP
(defclass pixmap (drawable)
()
(:metaclass x-class))
;;; DISPLAY
(defclass display (x-plist-mixin
external-object)
((protocol-major-version
:type card16
:reader protocol-major-version
:allocation :x-server)
(protocol-minor-version
:type card16
:reader protocol-minor-version
:allocation :x-server)
(vendor-name
:type string
:reader vendor-name
:allocation :x-server)
(release-number
:type card32
:reader release-number
:allocation :x-server)
(image-lsb-first-p
:type boolean
:reader image-lsb-first-p
:allocation :x-server)
(bitmap-formap
:type bitmap-format
:reader bitmap-formap
:allocation :x-server)
(pixmap-formats
:type (list pixmap-format)
:reader pixmap-formats
:allocation :x-server)
(roots
:type (list screen)
:reader roots
:allocation :x-server)
(motion-buffer-size
:type card32
:reader motion-buffer-size
:allocation :x-server)
(max-request-length
:type card16
:reader max-request-length
:allocation :x-server)
(min-keycode
:type card8
:reader min-keycode
:allocation :x-server)
(max-keycode
:type card8
:reader max-keycode
:allocation :x-server)
(error-handler
:type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
:initform #'display-handle-error
:initarg :error-handler
:accessor error-handler
:allocation :x-server)
(flush-handler
;; this was called "display-after-function"
:type (or null (function (display)))
:initform nil
:initarg :flush-handler
:accessor flush-handler
:allocation :x-server))
(:metaclass x-class))
;;; SCREEN
;;;
;;; Screens need not be explicitly created and opened. In some sense, they
;;; are substructures of display objects.
(defclass screen (x-object)
((root
:type window
:reader root
:initarg :root
:reader root
:allocation :x-server)
(width
:type card16
:initarg :width
:reader width
:allocation :x-server)
(height
:type card16
:initarg :height
:reader height
:allocation :x-server)
(width-in-millimeters
:type card16
:initarg :width-in-millimeters
:reader width-in-millimeters
:allocation :x-server)
(height-in-millimeters
:type card16
:initarg :height-in-millimeters
:reader height-in-millimeters
:allocation :x-server)
(depths
:type (alist (image-depth depth) ((list visual-info) visuals))
:initarg :depths
:reader depths
:allocation :x-server)
(root-depth
:type image-depth
:initarg :root-depth
:reader root-depth
:allocation :x-server)
(root-visual
:type card29
:initarg :root-visual
:reader root-visual
:allocation :x-server)
(default-colormap
:type colormap
:initarg :default-colormap
:reader default-colormap
:allocation :x-server)
(white-pixel
:type pixel
:initarg :white-pixel
:reader white-pixel
:allocation :x-server)
(black-pixel
:type pixel
:initarg :black-pixel
:reader black-pixel
:allocation :x-server)
(min-installed-maps
:type card16
:initarg :min-installed-maps
:reader min-installed-maps
:allocation :x-server)
(max-installed-maps
:type card16
:initarg :max-installed-maps
:reader max-installed-maps
:allocation :x-server)
(backing-stores
:type (member :never :when-mapped :always)
:initarg :backing-stores
:reader backing-stores
:allocation :x-server)
(save-unders-p
:type boolean
:initarg :save-unders-p
:reader save-unders-p
:allocation :x-server)
(event-mask-at-open
:type mask32
:initarg :event-mask-at-open
:reader event-mask-at-open
:allocation :x-server))
(:metaclass x-class))
;;; GCONTEXT
(defclass gcontext (external-object)
((drawable
:type drawable
:initform nil
:initarg :drawable
:accessor drawable
:allocation :x-server)
(boolean-function
:type (or null boole-constant)
:initform nil
:initarg :boolean-function
:accessor boolean-function
:allocation :x-server)
(plane-mask
:type (or null pixel)
:initform nil
:initarg :plane-mask
:accessor plane-mask
:allocation :x-server)
(foreground-color
:type (or null pixel)
:initform nil
:initarg :foreground-color
:accessor foreground-color
:allocation :x-server)
(background-color
:type (or null pixel)
:initform nil
:initarg :background-color
:accessor background-color
:allocation :x-server)
(line-width
:type (or null card16)
:initform nil
:initarg :line-width
:accessor line-width
:allocation :x-server)
(line-style
:type (or null (member :solid :dash :double-dash))
:initform nil
:initarg :line-style
:accessor line-style
:allocation :x-server)
(cap-style
:type (or null (member :not-last :butt :round :projecting))
:initform nil
:initarg :cap-style
:accessor cap-style
:allocation :x-server)
(join-style
:type (or null (member :miter :round :bevel))
:initform nil
:initarg :join-style
:accessor join-style
:allocation :x-server)
(fill-style
:type (or null (member :solid :tiled :opaque-stippled :stippled))
:initform nil
:initarg :fill-style
:accessor fill-style
:allocation :x-server)
(fill-rule
:type (or null (member :even-odd :winding))
:initform nil
:initarg :fill-rule
:accessor fill-rule
:allocation :x-server)
(arc-mode
:type (or null (member :chord :pie-slice))
:initform nil
:initarg :arc-mode
:accessor arc-mode
:allocation :x-server)
(tile
:type (or null pixmap)
:initform nil
:initarg :tile
:accessor tile
:allocation :x-server)
(stipple
:type (or null pixmap)
:initform nil
:initarg :stipple
:accessor stipple
:allocation :x-server)
(ts-x
:type (or null int16)
:initform nil
:initarg :ts-x
:accessor ts-x
:allocation :x-server)
(ts-y
:type (or null int16)
:initform nil
:initarg :ts-y
:accessor ts-y
:allocation :x-server)
(font
:type (or null fontable)
:initform nil
:initarg :font
:accessor font
:allocation :x-server)
(subwindow-mode
:type (or null (member :clip-by-children :include-inferiors))
:initform nil
:initarg :subwindow-mode
:accessor subwindow-mode
:allocation :x-server)
(exposures
:type (or null (member :on :off))
:initform nil
:initarg :exposures
:accessor exposures
:allocation :x-server)
(clip-x
:type (or null int16)
:initform nil
:initarg :clip-x
:accessor clip-x
:allocation :x-server)
(clip-y
:type (or null int16)
:initform nil
:initarg :clip-y
:accessor clip-y
:allocation :x-server)
(clip-mask
:type (or null (member :none) pixmap rect-seq)
:initform nil
:initarg :clip-mask
:accessor clip-mask
:allocation :x-server)
(clip-ordering
:type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded))
:initform nil
:initarg :clip-ordering
:accessor clip-ordering
:allocation :x-server)
(dash-offset
:type (or null card16)
:initform nil
:initarg :dash-offset
:accessor dash-offset
:allocation :x-server)
(dashes
:type (or null (or card8 (sequence card8)))
:initform nil
:initarg :dashes
:accessor dashes
:allocation :x-server)
(cache-p
:type boolean
:initform t
:initarg :cache-p
:accessor cache-p
:allocation :x-server))
(:metaclass x-class))
;;; CURSOR
(defclass cursor (external-object)
((source
:type pixmap
:initarg :source
:reader source
:allocation :x-server)
(mask
:type (or null pixmap)
:initform nil
:initarg :mask
:reader mask
:allocation :x-server)
(outside-left
:type card16
:initarg :outside-left
:reader outside-left
:allocation :x-server)
(outside-top
:type card16
:initarg :outside-top
:reader outside-top
:allocation :x-server)
(foreground-color
:type color
:initarg :foreground-color
:accessor foreground-color
:allocation :x-server)
(background-color
:type color
:initarg :background-color
:accessor background-color
:allocation :x-server))
(:metaclass x-class))
;;; GLIPH-CURSOR
(defclass gliph-cursor (cursor)
((source-font
:type font
:initarg :source-font
:reader source-font
:allocation :x-server)
(source-char
:type card16
:initarg :source-char
:reader source-char
:allocation :x-server)
(mask-font
:type font
:initarg :mask-font
:reader mask-font
:allocation :x-server)
(mask-char
:type card16
:initarg :mask-char
:reader mask-char
:allocation :x-server))
(:metaclass x-class))
;;; FONT
(defclass font (x-plist-mixin
external-object)
((display
:type display
:initarg :display
:reader display
:allocation :x-server)
(name
:type stringable
:initarg :name
:reader name
:allocation :x-server)
(direction
:type draw-direction
:reader direction
:allocation :x-server)
(min-char
:type card16
:reader min-char
:allocation :x-server)
(max-char
:type card16
:reader max-char
:allocation :x-server)
(min-byte1
:type card8
:reader min-byte1
:allocation :x-server)
(max-byte1
:type card8
:reader max-byte1
:allocation :x-server)
(min-byte2
:type card8
:reader min-byte2
:allocation :x-server)
(max-byte2
:type card8
:reader max-byte2
:allocation :x-server)
(all-chars-exist-p
:type boolean
:reader all-chars-exist-p
:allocation :x-server)
(default-char
:type card16
:reader default-char
:allocation :x-server)
(ascent
:type int16
:reader ascent
:allocation :x-server)
(decent
:type int16
:reader decent
:allocation :x-server))
(:metaclass x-class))
;;; COLORMAP
(defclass colormap (external-object)
((visual
:type card29
:initarg :visual
:reader visual
:allocation :x-server)
(window
:type window
:initarg :window
:reader window
:allocation :x-server)
(alloc-p
:type boolean
:initarg :alloc-p
:reader alloc-p
:allocation :x-server))
(:metaclass x-class))
;;; COLOR
(defclass color (external-object)
((red
:type rgb-val
:initform 0.0
:initarg :red
:accessor red
:allocation :x-server)
(green
:type rgb-val
:initform 0.0
:initarg :green
:accessor green
:allocation :x-server)
(blue
:type rgb-val
:initform 0.0
:initarg :blue
:accessor blue
:allocation :x-server))
(:metaclass x-class))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
#|
HANDLING X EVENTS
Events are handled by this system in one of two ways, by the EVENT-CASE
macro and by the PROCESS-EVENT function. EVENT-CASE gives the user
localized control over how X events are handled within the lexical scope of
a program. Since I am proposing little or no change to the existing CLX
EVENT-CASE macro, I will leave it out of this discussion.
PROCESS-EVENT invokes the default event handlers for a given class of
window. This is different from the current CLX in that handlers are
associated with window classes instead of just display objects. For each X
event type there is a corresponding handler method. This method is invoked
by dispatching off of the type of the event-window and the type of the
event. These methods would not be called by the user explicitly, but would
be called from within the PROCESS-EVENT function.
There are three alternatives to how to organize this multimethod dispatch:
1. By defining one event handler method for each type of event. Each of
these methods would do a single dispatch off of the type of window. (This
was the approach taken by Xenon.) The dispatch which invokes the method
corresponding to the event type is handled by magic inside PROCESS-EVENT.
Here are some examples:
(defmethod handle-key-press-event ((w window)
child
same-screen-p
x y root-x root-y
state
time
code)
...)
(defmethod handle-unmap-notify-event ((w window) configure-p)
...)
One advantage of this approach is that the user can write event handler
methods which dispatch off of other arguments as well. Here is an example
of how to use this type of handler:
(defclass active-border-window (window)
((event-mask
:initform '(:enter-notify :leave-notify))
(active-color
:type color
:accessor active-color)
(inactive-color
:type color
:accessor inactive-color)))
(defmethod handle-enter-notify-event ((w active-border-window) ...)
(with-slots (active-color) w
(setf (border-color w) active-color)))
(defmethod handle-leave-notify-event ((w active-border-window) ...)
(with-slots (inactive-color) w
(setf (border-color w) inactive-color)))
These methods, in some sense, become part of the class definition.
2. By using a single CLOS multimethod which does two dispatches: one off
of the type of window, and an EQL dispatch off of the event keyword. The
advantage of this approach is that the keywords correspond to the keywords
in the EVENT-CASE macro. Here are some examples of these methods:
(defmethod handle-event ((w window)
(event-keyword (eql :key-press))
&rest args)
...)
(defmethod handle-event ((w window)
(event-keyword (eql :key-release))
&rest args)
...)
The disadvantage of this is the &REST argument. This is necessary because
not all event handlers are called with the same arguments. It would be up
to the user to decipher the position of an argument in the ARGS list. An
alternative to this might be to use keyword arguments with &ALLOW-OTHER-KEYS.
3. The final approach would be to define actual event classes and dispatch
off the window instance and the event instance. (I believe XCL took this
approach.) Here's an example:
(defclass enter-notify-event (x-event)
((window
:type window
:accessor window)
(child
:type (or null window)
:accessor child)
...))
(defmethod handle-event ((w window) (e enter-notify-event))
...)
The advantage of this approach is that it makes the implicit hierarchy of X
event types explicit. Making this hierarchy explicit allows us to do some
interesting method lookup defaulting. One could imagine exploiting
multiple inheritance to provide increased flexibility:
(defclass key-press-event (key-event press-event)
...)
These new abstract event classes could be used by very general methods:
(defmethod handle-event ((w foo-window) (e press-event))
(format t "Something was pressed.~%"))
One question with this approach is how to map out this event hierarchy in
lisp. The X11 server doesn't really make any use of the hierarchy, and the
user may be fooled into thinking that subclassing an existing event class
would magically begin being utilized by CLX.
Another disadvantage to this is that generating CLOS objects for each X
event can be very expensive. Although using resource caches is possible
this still seems to be more trouble than its worth.
I recommend alternative 1.
|#
Respectfully submitted,
Warren Harris
∂28-Oct-88 0921 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 28 Oct 88 09:21:14 PDT
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
id AA21527; Fri, 28 Oct 88 09:17:14 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0)
id AA16756; Fri, 28 Oct 88 09:20:06 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA13108; Fri, 28 Oct 88 09:20:18 PDT
Message-Id: <8810281620.AA13108@suntana.sun.com>
To: Warren Harris <harris%hplwhh@hplabs.hp.com>
Cc: cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM,
hmuller%suntana@Sun.COM
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Your message of Thu, 27 Oct 88 17:34:01 -0700.
<3463.594002041@hplwhh>
Date: Fri, 28 Oct 88 09:20:15 PDT
From: kempf@Sun.COM
General Comments
----------------
CLX may be the wrong place to CLOSify. Pushing CLOS into the
Common Lisp kernel is a better long term solution in my opinion, if making the
low level interface to windows should be object oriented. This would
have the additional effect of allowing extensibility in other things,
like pathnames. For example, it would be nice to be able to extend
pathnames so that edit buffers could be used. That way, streams could
be opened on edit buffers without special machinery. Windows could benefit
as well.
A better short term solution is a host window system independent object-oriented
layer which targets to X via CLX as one option. Since there are other window
systems out there besides X (e.g. Coral Common Lisp runs on the Mac and targets
to the Mac window system), and, indeed, others may come along in the future,
it would rather seem more approprate to provide a "window virtual machine"
which abstracts away from the underlying host window system as much as
possible. This would isolate Lisp applications from the host window system,
and would fit more in with the general nature and philosophy of Lisp as
an abstraction away from the machine. The "window machine", in this case,
is X.
Specifics
---------
>In
>particular, a new meta-class is defined, X-CLASS, which makes convenient
>the specification of objects allocated external to the Lisp process (in the
>X server).
This new metaclass is a good idea, but why restrict it just to X? Why not
have a DISTRIBUTED-OBJECT metaclass?
>In this meta-class, a new slot-descriptor is defined,
>X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation,
>namely :X-SERVER. Specifying :X-SERVER allocation does not reserve space
>in the actual CLOS object for the value, but instead defines reader and
>writer methods which actually perform the X protocol requests. (There may
I don't understand why this is needed. This could be done with an
X-SERVER-MIXIN which is mixed with all the Lisp classes representing
X objects, then defining the appropriate qualified methods on the
slot accessor functions to perform the protocol requests. Is performance
a concern? If so, then won't the round trip server time dwarf the
amount of time needed to do the qualified method invocation?
My understanding of X is that the types of resources in the server
are not extensible. If so, then the qualified methods for slot access
can be defined and delivered as a nonextensible interface. So the
flexibility of a metaclass isn't needed.
>One difficulty with the old CLX model is that some objects are created in
>the server process simultaneous with their creation in the Lisp process.
>This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs. Other objects are
>created in the server process some time after their creation in the Lisp
>process. This includes DISPLAYs, and FONTs. This object-oriented
>version of CLX takes the uniform approach of delaying the creation of all
>server allocated objects until the OPEN-OBJECT generic function is called.
This will solve the problem of object creation, but it doesn't solve the
problem of co-ordinating asynchronous state changes in the client and server.
This is a general problem with programming using distributed objects.
>(Note: the way
>this works is that while a window is open, all :X-SERVER allocated instance
>variable accesses go through the X server. When the window is closed, the
>values of these slots as they currently exist in the server are re-cached
>in the lisp objects before the server object is actually destroyed. That
>way, the next time the window is opened the state is remembered.)
OK, now I understand how you propose to solve the cache consistency problem
between client and server-by simply not caching any state in the client!
Hmmm. What about performance? Having to go round trip to the server just
to figure out the height of a character in a multifont display could
slow display of a complex multifont view to a crawl.
> 2. It allows the objects' states to be remembered between Lisp
> sessions.
>
>This second point is a significant advantage since Lisp images can
>typically be stored on disk via some SAVE-WORLD command. Lisp images with
>saved CLX objects can then be recreated numerous times.
This is certainly an advantage, but an easier solution is to modify
the underlying CLX functions to do this. To me, the fact that
they don't do this already is a bug in CLX. This is not an inherent
advantage of your design.
>1. By defining one event handler method for each type of event. Each of
>these methods would do a single dispatch off of the type of window. (This
>was the approach taken by Xenon.) The dispatch which invokes the method
>corresponding to the event type is handled by magic inside PROCESS-EVENT.
> ...
>I recommend alternative 1.
This is way too inflexible. Event dispatch is not extensible, except by
subclassing windows.
>3. The final approach would be to define actual event classes and dispatch
>off the window instance and the event instance. (I believe XCL took this
>approach.)
This sounds like the right approach. Now, both window classes and event
classes are extensible.
>One question with this approach is how to map out this event hierarchy in
>lisp. The X11 server doesn't really make any use of the hierarchy, and the
>user may be fooled into thinking that subclassing an existing event class
>would magically begin being utilized by CLX.
If the event dispatcher is not chained to the X server, it may be possible
to define events inside Lisp which have nothing to do with the X server.
For example, one event might be VIEW-CHANGED, which would be used
by a Model/View/Controller type application framework to allow a model
(which may even be in a separate Unix process) to notify its views that
they should update themselves. By isolating event dispatch in one
place, multiprocessing code is reduced (for those Lisps which have
multiprocessing), thus reducing the need for concern about race conditions
and deadlocks.
>Another disadvantage to this is that generating CLOS objects for each X
>event can be very expensive. Although using resource caches is possible
>this still seems to be more trouble than its worth.
One or a few event objects per event type is not unreasonable.
Thanks for you ideas.
jak
∂31-Oct-88 1609 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 31 Oct 88 16:09:14 PST
Received: by ti.com id AA20832; Mon, 31 Oct 88 18:04:21 CST
Received: from dsg by tilde id AA23811; Mon, 31 Oct 88 17:58:47 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 31 Oct 88 17:57:58 CST
Message-Id: <2803334402-10970134@Sierra>
Sender: FileServer@Sierra.csc.ti.com
Date: Mon, 31 Oct 88 18:00:02 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Msg of Thu, 27 Oct 88 17:34:01 PDT from Warren Harris <harris%hplwhh@HPLABS.HP.COM>
I think it's a good idea to have a version of CLX which consists of CLOS classes
and generic functions and which thereby meshes directly with CLOS. For the most
part, I regard this as matter of implementation. Very little of the existing
CLX programmer interface ought to change. One of the few exceptions would be a
slightly different interface for process-event. But, destroy-window could
remain as an alias for (close-object window), all the accessor names could
remain, etc.
:x-server slots
I think it's correct not to allocate :x-server slots; the programmer
should have complete control over where to define client-side caches. What
about classes for which most programmers would prefer the slots to be cached
(e.g. fonts, gcontexts)? Perhaps CLX should define both cached and uncached
subclasses for these.
Why do the cursor and glyph-cursor classes define :x-server slots? These
values cannot be inquired via a protocol request. Same thing is true for
other classes and other slots (e.g. background slot of window). Such slots
are really just "initargs". But, if you separate make-instance and
open-object, then these have to be :allocation :instance. This sorta defeats
the idea of not allocating copies of server resources; is this an argument
against open-object?
The idea is that (slot-value object 'foo), where foo is :allocation :x-server,
will cause a server request, right? Otherwise, an :x-class metaclass would not
be necessary. A complication here is CLX's with-state macro. The following
forms must be equivalent.
(with-state (window)
(setf (window-x window) 100)
(setf (window-y window) 200))
(with-slots (x y) window
(with-state (window)
(setf x 100)
(setf y 200)))
(with-state (window)
(with-slots (x y) window
(setf x 100)
(setf y 200)))
Saving CLX objects
Good idea. But, I'm a little confused by the description. If no memory is
allocated for :x-server slots, then where do you cache values when the object
is closed?
Certain properties of a window depend on its display connection (e.g. depth),
so a saved window could only be opened if its display is also opened to
exactly the same host and display number. Right?
drawable
parent and border-width are window slots, not drawable slots. BTW, a window's
slot really ought to be setf'able, with optional new-x/new-y arguments
(generates a ReparentWindow request)
process-event
I prefer alternative #3, (defmethod handle-event ((w window-class) (e event-class))).
As Jim noted, this lets you define extended event types and then use
handle-event (outside of process-event) to dispatch events uniformly.
This alternative would be much improved if there actually was a way for CLX to
dispatch on programmer-defined subclasses *inside* process-event. It's not
clear how to implement this. Another thing is that I've noticed it's
frequently useful to define a new event subclass procedurally, either via a
relation predicate over its slots (e.g. :button-1-press, :shift-button-press,
etc.) or by a function of the event stream (e.g. :double-click). But, CLOS
doesn't handle these kind of (sub)classes.
∂01-Nov-88 1020 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from cheddar.cs.wisc.edu by SAIL.Stanford.EDU with TCP; 1 Nov 88 10:20:01 PST
Message-Id: <8811011817.AA20318@cheddar.cs.wisc.edu>
Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Tue, 1 Nov 88 12:17:36 CST
From: "David C. Martin" <dcmartin@cs.wisc.edu>
Organization: University of Wisconsin - Madison
Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin
Phone: 608/262-6624 (O)
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: Warren Harris <harris%hplwhh@hplabs.hp.com>, cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Mon, 31 Oct 88 18:00:02 CST
<2803334402-10970134@Sierra>
Subject: Re: OBJECT-ORIENTED CLX
Date: Tue, 01 Nov 88 12:17:31 -0600
Sender: dcmartin@cs.wisc.edu
I tend to agree with JAK that it would be better to leave CLX alone and work
on a higher-level abstraction (e.g. CommonWindows) at which to provide OO.
As for the question of event dispatching, there is a *lot* of overhead with
the use of:
(defmethod handle-event ((w window) (e event))
Especially in the cons'ing of the event object from the server data and the
lookup of the appropriate method. I tried this approach in my OO X window
system for V10 (XCLOS) and found that I typically handled the null event
function case (i.e. an event which caused nothing to happen) in about 75ms.
I was concerned with this performance problem, but wanted to retain the ability
to let the novice user write an event loop consisting of:
(loop (dispatch-event (get-next-event)))
In order to provide optimizations, I added a hashing mechanism on something
I called the _descriptor_ of an event (e.g. type) which could be quickly
retrieved from the raw (i.e. C language) event information. This descriptor
could then be hashed to a particular function or method which would expect
a raw event argument and might make use of low-level functions in order to
perform the handling.
Interestingly, the small loop did not have to change at all, but I was able
to hand-optimized and in-line the critical handlers for my window objects to
provide performance in the range of 18ms for the null event case.
I have always thought that it was best to provide several layers to any system,
with the top-level being easy to use, but perhaps slow when the novice defined
new objects, and the lower-levels integrating cleanly into the higher layers
and providing the expert with the ability to produce highly optimized code
which could make use of the underlying support system (e.g. CLX or XCL).
Lastly, I didn't quite understand the following:
----- from Kerry Kimbrough (10/31/88)
This alternative would be much improved if there actually was a way for CLX to
dispatch on programmer-defined subclasses *inside* process-event. It's not
clear how to implement this. Another thing is that I've noticed it's
frequently useful to define a new event subclass procedurally, either via a
relation predicate over its slots (e.g. :button-1-press, :shift-button-press,
etc.) or by a function of the event stream (e.g. :double-click). But, CLOS
doesn't handle these kind of (sub)classes.
------ end
Could you elucidate? I haven't used CLX enough to understand the limitation.
dcm
∂01-Nov-88 1102 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Nov 88 11:01:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 485403; Tue 1-Nov-88 13:56:14 EST
Date: Tue, 1 Nov 88 13:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: OBJECT-ORIENTED CLX
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>, David C. Martin <dcmartin@cs.wisc.edu>
cc: Warren Harris <harris%hplwhh@hplabs.hp.com>, cl-windows@sail.stanford.edu
In-Reply-To: <8811011817.AA20318@cheddar.cs.wisc.edu>
Message-ID: <19881101185545.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 01 Nov 88 12:17:31 -0600
From: "David C. Martin" <dcmartin@cs.wisc.edu>
Lastly, I didn't quite understand the following:
----- from Kerry Kimbrough (10/31/88)
This alternative would be much improved if there actually was a way for CLX to
dispatch on programmer-defined subclasses *inside* process-event. It's not
clear how to implement this. Another thing is that I've noticed it's
frequently useful to define a new event subclass procedurally, either via a
relation predicate over its slots (e.g. :button-1-press, :shift-button-press,
etc.) or by a function of the event stream (e.g. :double-click). But, CLOS
doesn't handle these kind of (sub)classes.
------ end
I'm not sure I understood it either. But if it means that you would like
to be able to have a predicate that controls whether a particular method
is applicable or not, like Common Lisp's SATISFIES type-specifiers or
guards in some other languages, CLOS doesn't have that, but it does have
something which gives about the same functionality: You can define your
own method-combination type, in which each method is optionally associated
with a predicate function, and the effective method form is a COND form
that calls the predicates and then calls the method for the first satisfied
predicate. Alternatively, you can use the builtin :OR method combination
type, and stick the predicates inside the bodies of the methods.
I hope this helps.
∂01-Nov-88 1539 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Nov 88 15:39:33 PST
Received: by ti.com id AA28906; Tue, 1 Nov 88 17:39:39 CST
Received: from dsg by tilde id AA19621; Tue, 1 Nov 88 15:32:04 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 1 Nov 88 15:31:05 CST
Message-Id: <2803411993-15631918@Sierra>
Sender: FileServer@Sierra.csc.ti.com
Date: Tue, 1 Nov 88 15:33:13 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Msg of Tue, 01 Nov 88 12:17:31 -0600 from "David C. Martin" <dcmartin@cs.wisc.edu>
> I tend to agree with JAK that it would be better to leave CLX alone and work
> on a higher-level abstraction (e.g. CommonWindows) at which to provide OO.
This point is controversial, but fortunately it is irrelevant to this discussion
of Warren's proposal for integrating CLX with CLOS.
> As for the question of event dispatching, there is a *lot* of overhead with
> the use of:
>
> (defmethod handle-event ((w window) (e event))
>
> Especially in the cons'ing of the event object from the server data and the
> lookup of the appropriate method.
This shouldn't be a problem. CLUE represents each input event as an instance of
the (single) event class, but minimizes cons'ing by reusing existing event
objects from a resource cache (typically, the cache is just one object).
Currently, the event class is a "union" of slots for all X events; those slots
which do not "belong" to the event-key have NIL values. But it wouldn't be hard
to extend this approach to 1 cache per event subclass.
I don't have CLUE performance numbers handy, but I'm certain allocation of event
objects is no bottleneck. Total user response time for typing/echoing a
character in a text editor contact is always adequate for interaction (could be
better, though). This includes lookup of the handler method, which in CLUE can
be complex and which has not even been optimized in the current version.
With (defmethod handle-event ((w window) (e event))), method lookup should be
fast, else you've got a poor implementation of CLOS, else CLOS has not acheived
its goal of efficient implementability.
> This alternative would be much improved if there actually was a way for CLX to
> dispatch on programmer-defined subclasses *inside* process-event. It's not
> clear how to implement this. Another thing is that I've noticed it's
> frequently useful to define a new event subclass procedurally, either via a
> relation predicate over its slots (e.g. :button-1-press, :shift-button-press,
> etc.) or by a function of the event stream (e.g. :double-click). But, CLOS
> doesn't handle these kind of (sub)classes.
What does this mean? Moon guessed correctly! I'd like to define an event
subclass with something like a SATISFIES type specifier. For example, a
button-1-press would be a subclass of a button-press event such that (= 1
(event-code event)). But, this can't be done directly, which is a CLOS fact,
not a CLX fact.
In the case of (defmethod handle-event ((w window) (e event))), then, the goal
would be for CLX to rely only on regular ol' CLOS method dispatch to
automatically pick the right effective handle-event method, not only with a
programmer-defined event class lattice (this is another problem entirely) but
also using these SATISFIES-type event subclasses (this is the aforementioned
CLOS problem; I'm still pondering Moon's suggested workaround).
∂01-Nov-88 1932 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from cheddar.cs.wisc.edu by SAIL.Stanford.EDU with TCP; 1 Nov 88 19:31:32 PST
Message-Id: <8811020329.AA22466@cheddar.cs.wisc.edu>
Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Tue, 1 Nov 88 21:29:11 CST
From: "David C. Martin" <dcmartin@cs.wisc.edu>
Organization: University of Wisconsin - Madison
Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin
Phone: 608/262-6624 (O)
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Tue, 1 Nov 88 15:33:13 CST
<2803411993-15631918@Sierra>
Subject: Re: OBJECT-ORIENTED CLX
Date: Tue, 01 Nov 88 21:29:05 -0600
Sender: dcmartin@cs.wisc.edu
Your message:
> This shouldn't be a problem. CLUE represents each input event as an
> instance of the (single) event class, but minimizes cons'ing by reusing
> existing event objects from a resource cache (typically, the cache is
> just one object)....
>
> I don't have CLUE performance numbers handy, but I'm certain allocation
> of event objects is no bottleneck. Total user response time for
> typing/echoing a character in a text editor contact is always adequate
> for interaction (could be better, though). This includes lookup of the
> handler method, which in CLUE can be complex and which has not even
> been optimized in the current version.
I implemented the cache stuff (and did it for all subclasses) and it only
saved me about 6ms. I think part of my performance problem was using PCL
and also I was running on a Sun3/280 and not dedicated LISP hardware. My
point was not that you can't make such a system work effectively, but there
are possibilities to make it work *better*. I don't think that any OO system
will ever perform as well as the underlying support (nb: the reasoning of
method dispatch being at best 1.5x a function dispatch) even given a totally
optimized CLOS. What I was looking for was a clean way to let the expert get
his stuff to go AFAP (as fast as possible), sorta like the C asm statement,
only better integrated and more portable.
> What does this mean? Moon guessed correctly! I'd like to define an
> event subclass with something like a SATISFIES type specifier. For
> example, a button-1-press would be a subclass of a button-press event
> such that (= 1 (event-code event)). But, this can't be done directly,
> which is a CLOS fact, not a CLX fact.
>
> In the case of (defmethod handle-event ((w window) (e event))), then,
> the goal would be for CLX to rely only on regular ol' CLOS method
> dispatch to automatically pick the right effective handle-event method,
> not only with a programmer-defined event class lattice (this is another
> problem entirely) but also using these SATISFIES-type event subclasses
> (this is the aforementioned CLOS problem; I'm still pondering Moon's
> suggested workaround).
Okay, now I get it. I wanted to do the same thing and found the exact
limitation that you encountered. What I did was extend my event handling
to allow for the descriptors of the raw events to be mapped to particular
subclasses of events which could then cons the appropriate event object.
For example, this would allow the user to specify that a CTL-META-X meant
repaint-window-event or some other totally non-window based event (e.g.
up-line-event). As for Moon's suggestion, I will have to peruse the CLOS
spec. for enlightenment.
dcm
∂01-Nov-88 2204 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 1 Nov 88 22:04:34 PST
Received: from RELAY.CS.NET by rand.org; Tue, 1 Nov 88 22:03:34 PST
Received: from [128.100.1.65] by RELAY.CS.NET id ab06046; 1 Nov 88 19:42 EST
Received: from jarvis.csri.toronto.edu by neat.ai.toronto.edu with SMTP id 8386; Tue, 1 Nov 88 19:33:43 EST
Received: by jarvis.csri.toronto.edu id 462; Tue, 1 Nov 88 19:32:58 EST
Received: from neat.ai.toronto.edu by jarvis.csri.toronto.edu with SMTP id 461; Tue, 1 Nov 88 19:32:10 EST
Received: by neat.ai.toronto.edu id 8342; Tue, 1 Nov 88 19:31:02 EST
Received: from localhost (stdin) by neat.ai.toronto.edu with SMTP id 8389; Tue, 1 Nov 88 19:30:46 EST
Subject: Re: OBJECT-ORIENTED CLX
Organization: Department of Computer Science, University of Toronto
References: <8811011817.AA20318@cheddar.cs.wisc.edu>
Distribution: list
Date: Tue, 1 Nov 88 22:49:43 EST
Sender: nobody%csri.toronto.edu@RELAY.CS.NET
Mmdf-Warning: Parse error in original version of preceding line at RELAY.CS.NET
From: Jean-Francois Lamy <lamy%ai.utoronto.ca@RELAY.CS.NET>
Message-Id: <88Nov1.193046est.8389@neat.ai.toronto.edu>
To: lispx@rand.org
Can someone provide me with a succint summary of the essential features of
CLX, CLUE, CLOS, CommonWindows and how they relate to each other?
Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
∂02-Nov-88 0445 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 2 Nov 88 04:45:21 PST
Received: from hplms2.hpl.hp.com by RELAY.CS.NET id aa12523; 2 Nov 88 3:03 EST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 1 Nov 88 23:52:56 pst
Received: from loopback by hplwhh.HPL.HP.COM; Tue, 1 Nov 88 23:52:03 pst
Full-Name: Warren Harris
To: "David C. Martin" <dcmartin@CS.WISC.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Your message of "Tue, 01 Nov 88 12:17:31 CST."
<8811011817.AA20318@cheddar.cs.wisc.edu>
Date: Tue, 01 Nov 88 23:51:58 PST
Message-Id: <8272.594460318@hplwhh>
From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
> From: "David C. Martin" <dcmartin@cs.wisc.edu>
>
> I tend to agree with JAK that it would be better to leave CLX alone and work
> on a higher-level abstraction (e.g. CommonWindows) at which to provide OO.
I guess I don't agree with JAK about this at all. We can always keep
envisioning the great all-encompassing object-oriented window system, but
at some point somebody has to design and build it. OO-CLX is a first-pass
at such a design. Moreover, CLX is an interface to X11, not a "generic"
window system. As pointed out earlier, the problem with a generic window
system is that the common denominator between all window systems is much
too low. If CLX can be used as an implementation of a generic window
system, then that's good. Similarly if the Mac toolkit can be used to
implement the same generic window system on another machine, then that's
good too. None of that has any bearing on the design of an X11 interface
though.
I do agree with JAK that there are many places in the CL kernel which could
be objectified. Pathnames and streams are obvious ones. The fact that
this hasn't happened yet for pathnames and streams shouldn't prevent us
from designing CLX in the way we'd like all things to be ultimately.
I want to reiterate again why I think approach 1 to event dispatching is
best. One could imagine writing a hairy method combination for which could
create combined methods that dispatched off the types of slots inside
object, or a subclass of generic-function which knew how to discriminate on
SATISFIES type-specifiers. However, there's a simple way to get
essentially this same functionality without meta-programming. The solution
is to write two generic-functions:
(defmethod handle-event ((w my-window) (e button-press-event))
(handle-button-press-event w
(slot-value e 'code)
...))
(defmethod handle-button-press-event ((w my-window)
(code (eql :button-1-press))
...)
...)
You may argue that this would take twice as long (two dispatches), but who
knows how long a SATISFIES type-specifier would take.
The reason I'm not suggesting this approach is that I've found in practice
that the second (inner) method is almost always what you want. Now if the
call to HANDLE-BUTTON-PRESS-EVENT was done by PROCESS-EVENT directly, this
is exactly approach 1. This problem doesn't typically come up in most CLOS
programming because people write their methods to discriminate on the
objects that matter, not on some parent object which holds the objects that
matter in instance variables.
As I pointed out in my original message, X is not going to start sending
out new events which are subtypes of events defined in the protocol spec,
so why should the user be allowed to subclass event objects? Also, why
cons (or use resources) for event objects that are immediately going to be
destructured in the discrimination process? This is *very* expensive.
Also approach 1 is roughly equivalent to what CLX is doing now with its
handler call-back functions. Instead of taking keyword arguments though,
the arguments are in-place so methods can discriminate on them if they
choose to.
> From: "David C. Martin" <dcmartin@cs.wisc.edu>
>
> I was concerned with this performance problem, but wanted to retain the ability
> to let the novice user write an event loop consisting of:
>
> (loop (dispatch-event (get-next-event)))
>
> In order to provide optimizations, I added a hashing mechanism on something
> I called the _descriptor_ of an event (e.g. type) which could be quickly
> retrieved from the raw (i.e. C language) event information. This descriptor
> could then be hashed to a particular function or method which would expect
> a raw event argument and might make use of low-level functions in order to
> perform the handling.
>
> Interestingly, the small loop did not have to change at all, but I was able
> to hand-optimized and in-line the critical handlers for my window objects to
> provide performance in the range of 18ms for the null event case.
I was really trying to avoid the need to hand-code special event handlers.
It is extremely difficult for the users to do to optimize his application.
> I have always thought that it was best to provide several layers to any system,
> with the top-level being easy to use, but perhaps slow when the novice defined
> new objects, and the lower-levels integrating cleanly into the higher layers
> and providing the expert with the ability to produce highly optimized code
> which could make use of the underlying support system (e.g. CLX or XCL).
I think this approach requires the users to be experts to get any real work
done. The problem with streamlining one layer and building an "extensible"
and easy to use layer on top of it is that it creates a very large gap
between what's easily doable and what's tollerable. Pushing
object-oriented programming to a layer on top of CLX has exactly this
pitfall. I'd rather see CLX be designed with performance AND extensablity
in mind up front.
> From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
>
> I don't have CLUE performance numbers handy, but I'm certain allocation of event
> objects is no bottleneck. Total user response time for typing/echoing a
> character in a text editor contact is always adequate for interaction (could be
> better, though). This includes lookup of the handler method, which in CLUE can
> be complex and which has not even been optimized in the current version.
Has anyone really done any performance analysis comparing CLUE to the
XToolKit for instance. I think they'd be surprised.
Other comments:
> From: kempf@Sun.COM
>
> This new metaclass is a good idea, but why restrict it just to X? Why not
> have a DISTRIBUTED-OBJECT metaclass?
Because the way this meta-class operates strongly depends on what is
distributed and where. Surely a class which communicates with a database
would have a different meta-class than one which communicates with the X
server. Are you suggesting a meta-meta-class? {e.g. type-of(window) =
x-class; type-of(x-class) = distributed-object; type-of(personnel-record) =
db-class; type-of(db-class) = distributed-object;
type-of(distributed-object) = ?? }
> From: kempf@Sun.COM
>
> >In this meta-class, a new slot-descriptor is defined,
> >X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation,
> >namely :X-SERVER. Specifying :X-SERVER allocation does not reserve space
> >in the actual CLOS object for the value, but instead defines reader and
> >writer methods which actually perform the X protocol requests. (There may
>
> I don't understand why this is needed. This could be done with an
> X-SERVER-MIXIN which is mixed with all the Lisp classes representing
> X objects, then defining the appropriate qualified methods on the
> slot accessor functions to perform the protocol requests. Is performance
> a concern? If so, then won't the round trip server time dwarf the
> amount of time needed to do the qualified method invocation?
> My understanding of X is that the types of resources in the server
> are not extensible. If so, then the qualified methods for slot access
> can be defined and delivered as a nonextensible interface. So the
> flexibility of a metaclass isn't needed.
The idea here was to streamline the definition process (and indirectly
document CLX's operation/intention). The way I envision this actually
working is that information regarding the actual protocol request will be
declaratively specified with the slot descriptor information:
(defclass drawable (x-plist-mixin
external-object)
(...
(outside-left
:type int16
:initform 0
:initarg :outside-left
:reader outside-left
:allocation :x-server
:request-buffer-size 16
:request-buffer-position 12
:request-buffer-request-code ...)
...))
And this would automatically generate something like:
(defmethod outside-left ((d drawable))
(with-request-buffer (b :size 16
:request-code ...)
(buffer-get b :type 'int16 :position 12)))
(defmethod (setf outside-left) ((d drawable)) (value)
(with-request-buffer (b :size 16
:request-code ...)
(buffer-set b value :type 'int16 :position 12)))
(I am of course exercising both imaginative and wishful thinking here.)
Maybe a real implementation would have the methods explicitly written, and
the :X-SERVER slot-descriptors simply would not allocate space in the
X-CLASS instances. Note that the :X-SERVER declaration is necessary
because not all slots in an instance will be allocated in the server. In
particular, subclasses of window will want to hold their own local data.
Sure, a new meta-class is not required, but then again, meta-classes are
never required. Anything defined with them could be defined by regular
classes. They just make life easier for the programmer, and things more
understandable by the user.
> >One difficulty with the old CLX model is that some objects are created in
> >the server process simultaneous with their creation in the Lisp process.
> >This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs. Other objects are
> >created in the server process some time after their creation in the Lisp
> >process. This includes DISPLAYs, and FONTs. This object-oriented
> >version of CLX takes the uniform approach of delaying the creation of all
> >server allocated objects until the OPEN-OBJECT generic function is called.
>
> This will solve the problem of object creation, but it doesn't solve the
> problem of co-ordinating asynchronous state changes in the client and server.
> This is a general problem with programming using distributed objects.
No. WITH-STATE is still needed for that. Also things like
WITHOUT-INTERRUPTS.
> OK, now I understand how you propose to solve the cache consistency problem
> between client and server-by simply not caching any state in the client!
> Hmmm. What about performance? Having to go round trip to the server just
> to figure out the height of a character in a multifont display could
> slow display of a complex multifont view to a crawl.
The implementation is free to cache whatever it sees fit. Xenon in
particular did this and allowed certain events to update the cache. This
way, many server requests were eliminated.
> From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
>
> I think it's a good idea to have a version of CLX which consists of CLOS classes
> and generic functions and which thereby meshes directly with CLOS. For the most
> part, I regard this as matter of implementation. Very little of the existing
> CLX programmer interface ought to change.
On the surface this may seem true, but there is a fundamental difference.
Requiring CLX to be object-oriented would change the way applications would
use it. The function names could stay the same, but given the ability to
subclass CLX objects and override or specialize primitive methods, a
toolkit layer like CLUE could be implemented without building yet another
paradigm (CONTACTS). CONTACTS are also only the tip of the iceberg. What
happens when the user wants to specialize COLOR, or FONT? Xenon allowed
this and it made it possible for users to write things like and OPEN FONT
method which looked in the color map for a "close" color, (were "close
enough" was itself a specializable criterion (method)).
> Why do the cursor and glyph-cursor classes define :x-server slots? These
> values cannot be inquired via a protocol request. Same thing is true for
> other classes and other slots (e.g. background slot of window). Such slots
> are really just "initargs".
Yes, you're right that some of those slots shouldn't be :x-server
allocated (I got carried away).
> But, if you separate make-instance and
> open-object, then these have to be :allocation :instance. This sorta defeats
> the idea of not allocating copies of server resources; is this an argument
> against open-object?
I was thinking that you could just save the init-plist on the object when
you did a MAKE-INSTANCE call. This would require just 1 slot. OPEN-OBJECT
would then take the init-plist apart. CLOSE-OBJECT could build a new
"init-plist" for the next time the object is opened, by querying the server
for all the object's attributes before it actually issued the destroy
request. The alternative is to actually allocate all the :X-SERVER slots
with :INSTANCE allocation, and use these slots as caches when necessary.
Regardless of whether or not we separate the lisp object creation from the
X server object creation, I think CLX should present itself as an
object-oriented interface. In doing so, the meta-classes and slot
allocations are still useful concepts.
Warren
∂02-Nov-88 0837 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from cheddar.cs.wisc.edu by SAIL.Stanford.EDU with TCP; 2 Nov 88 08:26:16 PST
Message-Id: <8811021624.AA23108@cheddar.cs.wisc.edu>
Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Wed, 2 Nov 88 10:24:22 CST
From: "David C. Martin" <dcmartin@cs.wisc.edu>
Organization: University of Wisconsin - Madison
Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin
Phone: 608/262-6624 (O)
To: Warren Harris <harris%hplwhh@hplabs.hp.com>
Cc: cl-windows@sail.stanford.edu
Precedence: special-delivery
In-Reply-To: Your message of Tue, 01 Nov 88 23:51:58 PST
<8272.594460318@hplwhh>
Subject: Re: OBJECT-ORIENTED CLX
Date: Wed, 02 Nov 88 10:24:17 -0600
Sender: dcmartin@cs.wisc.edu
Okay, so lets drop the discussion of where to perform OO thingies and talk
about how to build something on top of CLX to make it easier to use.
Granted that an object-oriented interface to *anything* makes it easier to
use, but it must also be noted that when you OO'ify anything your performance
degrades to a certain extent.
In the case of CLX we have a nice platform to access a non-OO system (i.e. X),
and we could potentially expand CLX to contain OO'ism and make it more useful
(or should I say usable). In any event, the question of changing a primary
interface like CLX, which many people may wish to utilize w/o OO additions,
does not seem to make much sense (e.g. should we change the UNIX system call
interface to only be C++?).
The question then becomes ``what should we build on *top* of CLX to make it
better for our particular application domain?'' Let's say that we want to
build an object-oriented CLX (CLX++) which provides all the functionality of
CLX, but is located in the xlib++ package (don't flame about the dumb names).
If we utilize this type of strategy we can preserve the primary interface and
make use of its functionality and at the same time override the neccessary
low-level functionality for any modifications we see fit.
So now lets look at what we want to change. Well, Kerry wants to have
a SATISFIES subclassing mechanism for event processing. Moon tells us that
there is some CLOS magic to get this functionality, and Warren doesn't think
that it will be fast enough. There is also the question of why even provide
something like this feature when what you obviously want is two-levels of
method discrimination. In addition, I said that you could allow an experienced
programmer to utilize hooks to speed up event processing to avoid the cons'ing
of event objects and gratuitous method discrimination -- I hope you understood
that I didn't expect the CLX++ programmer to understand *all* of CLX, but only
how to make use of the hooks in CLX++ to access certain functions and
structures defined at the CLX level.
Whew! A lot of differing viewpoints and amazingly enough I think these
different ideas support the notion that no one implementation will serve the
needs of all users.
Warren writes:
As I pointed out in my original message, X is not going to start sending
out new events which are subtypes of events defined in the protocol spec,
so why should the user be allowed to subclass event objects? Also, why
cons (or use resources) for event objects that are immediately going to be
destructured in the discrimination process? This is *very* expensive.
Sure it's expensive, but for the novice it makes using the system very
easy and for both the expert and the novice it makes debugging a *lot*
easier (trust me, I made extensive use of this feature when using my *own*
system - I guess that would make me an expert :-). No one ever said that you
always had to cons up event objects.
Warren again:
I think this approach requires the users to be experts to get any real work
done. The problem with streamlining one layer and building an "extensible"
and easy to use layer on top of it is that it creates a very large gap
between what's easily doable and what's tollerable. Pushing
object-oriented programming to a layer on top of CLX has exactly this
pitfall. I'd rather see CLX be designed with performance AND extensablity
in mind up front.
I also would love to see CLX have super performace and be totally extensible,
sounds great... uh, I don't think you can do this trick, 'cause the users will
always come back and say ``make it faster'' and any OO'ism you add are going to
require a performance hit. In the design I implemented for XCL and XCLOS, the
users were not experts, but the hooks provided made it extremely easy for
any programmer to determine bottlenecks in her code and avoid making use of
the OO stuff in the XCLOS layer. For example, lets look at a simple example:
(let ((event (make-instance 'enter-window)))
(setf (state event) :ignored)
(make-event-map-entry a-text-menu-item-window
:event event
:function #'enter-window-event-handler)
(free event))
(defmethod enter-window-event-handler ((self text-menu-item) (event integer))
(declare (ignore event))
(cond
((plusp (xcl:x-pending))
(let ((e (xcl:x-next-event)))
(if (and (= (xcl:x-event-window e) (id self))
(= (xcl:x-event-type e) xcl:*leave-window*))
(return-from enter-window-event-handler nil))
(xcl:x-invert-window (id self))
(dispatch-event e)))
(t (xcl:x-invert-window (id self)))))
(defmethod default-handler ((self text-menu-item) (event enter-window))
(declare (ignore event))
(cond
((plusp (events-pending))
(let ((e (get-next-event)))
(if (and (eq (window e) self)
(eq (class-of e) (class-named 'leave-window)))
(return-from default-handler nil))
(invert self)
(dispatch-event e)))
(t (invert self))))
In this example, the default-handler() is the method which is utilized if there
is no mapping for an event-window event on a text-menu-item window. However,
when the mapping for the event exists, the system will make use of the
optimized method. It is a method in this example since I might want to make
use of the text-menu-item enter-window-event-handler in some subclass of
text-menu-item.
I guess what I really want to get across is that most novices can become
experts if the system gives them a gradual learning curve and does not say that
they must either know everything, or not be able to utilize underlying
features. I took it from your comment that you didn't think that such a path
could be implemented, but the hooks I built into XCLOS provided various paths
to encourage the user to optimize various aspects of her code, w/o having to
know a lot about XCL.
I would hope that whatever is built on top of CLX retains the original CLX
interface and allows the users of the new system to make use of supported
hooks to optimize their code.
dcm
∂03-Nov-88 1034 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Nov 88 10:34:00 PST
Received: by ti.com id AA14076; Thu, 3 Nov 88 12:34:04 CST
Received: from dsg by tilde id AA08172; Thu, 3 Nov 88 12:20:49 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 3 Nov 88 12:19:53 CST
Message-Id: <2803573317-8809428@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 3 Nov 88 12:21:57 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Msg of Wed, 02 Nov 88 10:24:17 -0600 from "David C. Martin" <dcmartin@CS.WISC.EDU>
> Date: Wed, 02 Nov 88 10:24:17 -0600
> From: "David C. Martin" <dcmartin@CS.WISC.EDU>
>
> In any event, the question of changing a primary
> interface like CLX, which many people may wish to utilize w/o OO additions,
> does not seem to make much sense (e.g. should we change the UNIX system call
> interface to only be C++?).
Good point; I share this concern.
> The question then becomes ``what should we build on *top* of CLX to make it
> better for our particular application domain?''
Or rather: how far "above" existing CLX do we draw a new line? What Warren
seems to be saying is "not far -- just enough to smoothly CLOSify the existing
CLX functionality." I like this answer. It's useful, not only because it will
simplify the construction of X-based OOUI systems with truly higher-level
features, but also because it appears that many designers of OO interactive
programs would like to plug in at exactly this level. Moreover, it's doable.
Contrast this with the difficulty of designing the chimerical "standard Common
Lisp window system", much less one designed to suit a "particular application
domain".
The approach I would favor is a CLOSified CLX which would preserve *all*
existing CLX interfaces, with rare exceptions where there is an overriding
advantage. I expect this would appear in a new package -- CLOSX ("Cloth
Eggs"??!!), anyone?
∂03-Nov-88 1123 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Nov 88 11:23:01 PST
Received: by ti.com id AA14293; Thu, 3 Nov 88 13:19:18 CST
Received: from dsg by tilde id AA09130; Thu, 3 Nov 88 13:07:09 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 3 Nov 88 13:06:10 CST
Message-Id: <2803576072-8974937@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 3 Nov 88 13:07:52 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Cc: "David C. Martin" <dcmartin@CS.WISC.EDU>, cl-windows@SAIL.STANFORD.EDU
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Msg of Tue, 01 Nov 88 23:51:58 PST from Warren Harris <harris%hplwhh@HPLABS.HP.COM>
> Date: Tue, 01 Nov 88 23:51:58 PST
> From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
>
> I want to reiterate again why I think approach 1 to event dispatching is
> best.
OK, you convinced me.
> > Very little of the existing
> > CLX programmer interface ought to change.
>
> On the surface this may seem true, but there is a fundamental difference.
> Requiring CLX to be object-oriented would change the way applications would
> use it.
Agreed -- (not (eq clx oo-clx)). But (equalp clx oo-clx)? My point is spelled
out perhaps more clearly in my reply to David: we're talking about a system
which, by definition, is the same as CLX (not strictly but in a strong sense).
Similarly, CLOS is designed to mesh smoothly with non-OO Lisp functions.
Therefore, there is little reason for OOCLX to diverge from CLX -- neither
semantically nor syntactically. Where divergence can be soundly justified,
fine. But the rule of thumb should be "same until proven different".
On a practical note, CLX is already carefully designed to match up well with the
interfaces and terminology of the X protocol. Tinker with this gratuitously
(e.g. x -> outside-left) and you'll be overwhelmed by the moans, squawks, and
bleeps of the multitude of hackers already laboring away in the sulphurous lower
circles. No, don't look at it that way; look at it this way: it'll make the
transition from CLX to OOCLX cheaper.
> I was thinking that you could just save the init-plist on the object when
> you did a MAKE-INSTANCE call. This would require just 1 slot. OPEN-OBJECT
> would then take the init-plist apart. CLOSE-OBJECT could build a new
> "init-plist" for the next time the object is opened, by querying the server
> for all the object's attributes before it actually issued the destroy
> request. The alternative is to actually allocate all the :X-SERVER slots
> with :INSTANCE allocation, and use these slots as caches when necessary.
OK, I think the init-plist is a good idea.
∂05-Nov-88 2027 CL-Windows-mailer clx on an Apollo
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 5 Nov 88 20:27:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad12013; 5 Nov 88 13:05 EST
Received: from software.org by RELAY.CS.NET id ba06813; 5 Nov 88 12:11 EST
Received: by spc-gould (5.52/5.17)
id AA19365; Fri, 4 Nov 88 16:31:27 EST
Date: Fri, 4 Nov 88 16:31:27 EST
From: Aaron Temin <temin@software.org>
To: cl-windows@SAIL.STANFORD.EDU
Subject: clx on an Apollo
I'm having troubles getting clx to do its thing on my Apollo. Can
someone out there lend a hand?
I managed to fiddle with release 2 and get it to load, but when I
ran hello-world it couldn't connect to the server (though socket.o
seemed to work fine by itself). I can't even get release 3 to load --
it does with the message
>>Error: GET-PUT-ITEMS has no global function definition
SYMBOL-FUNCTION:
Required arg 0 (S): GET-PUT-ITEMS
This happens when I do (load-clx) after having loaded defsystem.lisp.
I'm running (Lucid) CommonLisp v. 1.04 on an Apollo DN3000 (b/w) with
SR 9.7.
Thanks in advance,
Aaron Temin csnet: temin@software.org
Software Productivity Consortium
1880 Campus Commons Drive, North
Reston, VA 22091 arpanet: temin%software.org@relay.cs.net
∂09-Nov-88 1120 CL-Windows-mailer Status.of.CLOS.and.associated.software.for"production"work
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88 11:20:25 PST
Received: by ti.com id AA12695; Wed, 9 Nov 88 13:20:35 CST
Received: from dsg by tilde id AA18080; Wed, 9 Nov 88 13:07:25 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 9 Nov 88 13:06:40 CST
Message-Id: <2804094400-13789232@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 9 Nov 88 13:06:40 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Status.of.CLOS.and.associated.software.for"production"work
------- Forwarded Message
Date: Wed, 9 Nov 88 12:09:27 EST
From: Status.of.CLOS.and.associated.software.for"production"work@summanulla.mc.duke.edu
To: CommonLoops.pa@Xerox.COM
Redistributed: CommonLoops.pa
I am about to start coding a proof-of-principle system to go with my
dissertation research in domain-specialized programming languages/
visual programming systems. I have been entertaining the idea that
Common Lisp, CLOS, and X Windows would be an appropriate programming
environment for this; I'm not that experienced a Lisp programmer,
however, so I have some questions. I'd be happy to hear anyone's
opinion on the questions.
For all of these questions, please keep in mind that the only Common
Lisp I have available is KCL (with the Austin modifications, although I
could rebuild without if necessary.)
(1) How stable is CLOS at this point? How likely am I to exercise
significant bugs that are difficult to work around?
(2) Is there a significant amount of CLOS code available, so I have some
good examples from which to learn coding style inclusive-or dirty but
useful tricks?
(3) The only OOP interface to X windows of which I am aware is CLUE.
How stable is CLUE? What has been others's experience coding
applications using CLUE? Are there other interfaces I should consider?
Should I consider building my own toolkit directly from CLX?
(4) is there available an EMACS-like editor, in the public domain or
freely usable, that is portable to Common LISP directly? I can always
run a subsidiary GNU Emacs or emacsclient, but I'd rather have a
slightly crippled LISP emacs I can put my own hooks into.
(I plan to encapsulate it in an editor-object anyway, so compatibility
with CLOS doesn't seem an issue. Am I wrong?)
Thanks everyone,
Charlie Martin
(...!mcnc!duke!crm, crm@summanulla.mc.duke.edu)
(if summanulla doesn't work, use crm@cs.duke.edu)
------- End of Forwarded Message
∂09-Nov-88 2218 CL-Windows-mailer Re: OBJECT-ORIENTED CLX
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 9 Nov 88 22:18:27 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 8 Nov 88 11:25:39 pst
Received: from loopback by hplwhh.HPL.HP.COM; Tue, 8 Nov 88 11:24:40 pst
Full-Name: Warren Harris
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: OBJECT-ORIENTED CLX
In-Reply-To: Your message of "Thu, 03 Nov 88 13:07:52 CST."
<2803576072-8974937@Sierra>
Date: Tue, 08 Nov 88 11:24:37 PST
Message-Id: <13639.595020277@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
> On a practical note, CLX is already carefully designed to match up well with the
> interfaces and terminology of the X protocol. Tinker with this gratuitously
> (e.g. x -> outside-left) and you'll be overwhelmed by the moans, squawks, and
> bleeps of the multitude of hackers already laboring away in the sulphurous lower
> circles. No, don't look at it that way; look at it this way: it'll make the
> transition from CLX to OOCLX cheaper.
I agree. I was caught in a dilemma between accessor prefixes and bad
function names, so I got a little gratuitous. My logic was that if I want
to access the X slot of something, I don't want to have to remember if that
done by DRAWABLE-X, WINDOW-X or something else. On the other hand, an
accessor named X is a pretty bad name. Also, I used to always forget
whether the x and y coordinates were inside or outside of the borders, and
whether the width and height included the borders or not (and do drawables
have borders?). I assumed others might forget too, so I added the INSIDE-
and OUTSIDE- prefixes. Oh well, change it all back...
Warren
∂11-Nov-88 1156 CL-Windows-mailer PCL, CLX, and CLUE in KCL
Received: from fs3.cs.rpi.edu by SAIL.Stanford.EDU with TCP; 11 Nov 88 11:55:50 PST
Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept)
id AA01885; Fri, 11 Nov 88 14:53:18 EST
Date: Fri, 11 Nov 88 14:53:17 EST
From: harrisr@turing.cs.rpi.edu (Richard Harris)
Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept)
id AA15538; Fri, 11 Nov 88 14:53:17 EST
Message-Id: <8811111953.AA15538@turing.cs.rpi.edu>
To: cl-windows@sail.stanford.edu, commonloops.pa@xerox.com
Subject: PCL, CLX, and CLUE in KCL
I have put the versions of AKCL, PCL, CLX, and CLUE
that I use in the directory pub/lisp, on the host turing.cs.rpi.edu,
for anonymous ftp retrieval.
The AKCL is akcl-1-79 (KCL with enhancements by Bill Schelter), with
additional enhancements that I made.
The PCL is named "8/28/88 (beta rev 1) AAAI PCL ", but includes a couple
of patches that Gregor Kiczales sent to the commonloops list, and a
bunch of patches I made to improve PCL's performance in KCL.
The CLX is a version that TI made available along with CLUE version 1.15.
And CLUE is CLUE version 1.15.
I have made patches to KCL and CLUE to make INTERACTIVE-STREAMS work in KCL.
I have not tested these systems very much, and you will probably discover bugs:
for instance, KCL's (lack of) support for SETF CHAR-BIT causes problems
for CLX.
I have created a mailing list for people who use this version of KCL,
called kcl-x@turing.cs.rpi.edu (with kcl-x-request@turing.cs.rpi.edu)
Rick Harris
∂17-Nov-88 0706 CL-Windows-mailer mailing list
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 17 Nov 88 07:06:31 PST
Full-Name: Elaine Lusher
Message-Id: <8811171455.AA20938@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: cl-windows@sail.stanford.edu
Subject: mailing list
Date: Thu, 17 Nov 88 09:55:37 EST
From: lusher@mitre.arpa
please add me to the mailing list for lisp user interface programming.
I'm interested in x and clue in particular. Thanks!
lusher@mitre.arpa
∂18-Nov-88 0702 CL-Windows-mailer common lisp stream to an X window
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 18 Nov 88 07:02:23 PST
Date: 18 Nov 88 09:35:30 EST
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
I'd like to be able to get a stream to an X window.
I've read the X code and the CLX code (CMU MACH on RT) and
I'm losing. There doesn't seem to be a LISP stream associated
with a window (however, there DOES seem to be a unix stream (?)
associated with a window ).
Specifically, I'd like to be able to do one of (in decreasing
order of interest, increasing order of hacking):
(READ (WINDOW-STREAM window))
;; if there is only the display stream, not window streams then
(WHEN (INSIDE-MY-WINDOWP) (READ (DISPLAY-STREAM window)))
;; or, if there is only a way to get characters then I can
;; construct a stream by building a text-in method for the reader
(DEFUN TEXT-IN ()
(WHEN (STREAM-BUFFER-EMPTYP) (FILL-STREAM-BUFFER))
(SVREF STREAM-BUFFER INDEX))
(SETF (STREAM-INPUT-FUNCTION window-stream) #'TEXT-IN)
(READ (WINDOW-STREAM window))
I realize that this notion is wrong in the world of X because
X assumes that my program is one big event loop and that I have
a function that handles key presses. I could, I suppose, write
a hack to fill the stream buffer using a key press function but
I don't see how this can be coordinated with READ, READ-CHAR,
LISTEN, etc.
In any case, I need LISP READER input from a window.
Any ideas would be greatly appreciated.
Tim Daly
DALY@IBM.COM
T.J.Watson Research Center
Yorktown Heights, N.Y.
∂30-Nov-88 1215 CL-Windows-mailer common lisp stream to an X window
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
∂02-Dec-88 0704 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <jho%hutcs.hut.fi@Forsythe.Stanford.EDU>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: cl-windows@sail.stanford.edu, clue-review@dsg.csc.ti.com
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
∂02-Dec-88 0709 CL-Windows-mailer streams to common lisp windows.
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:08:56 PST
Date: 1 Dec 88 11:06:47 EST
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <120188.110651.daly@ibm.com>
Subject: streams to common lisp windows.
Well, I HAVE succeeded in implementing a function that will return
the READ of a window. It is truly ugly but it works. The essential
steps are:
catch :exit
event-case to capture keycodes (NOT ascii)
when :key-press
convert key to ascii
when key is of type character
concat to buffer
if key is a constituent char
then exit event-case
else continue event-case
event-case to throw away the key event (discard-p t)
condition-case (with-input-from-string (s buffer) (setq result (read s)))
on simple-condition-error (setq result :fail)
unless (eq result :fail) (throw :exit result)
essentially, i capture each key-press event, convert it to ascii,
and if it is an ascii character I add it to the buffer. The constituent
character check is there to wait until there is some terminating input
character before calling READ (else 376 is returned as 3 (read succeeds
early)).
next, i have to throw away the key-press event from the event queue
since it was requeued by exiting the first event-case
then, i use the condition system to keep READ safe from errors and
attempt a READ on the buffer. If READ succeeds (it might be reading
a partial list and fail) then I return the result, else I continue.
I understand that this is incredibly clanky but X-Windows wants me
to write my program as an EVENT-CASE structure and other window
systems will allow READs to windows. My code is designed to port
to other window systems.
One (flame-like) comment: X-Windows is designed as a policy-free
window system but it strongly constrains the designs of programs
that use it. Methinks this might need discussion.
Tim
DALY@IBM.COM
IBM T.J.Watson Research Center
Yorktown Heights, N.Y. 10598
∂02-Dec-88 1150 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 11:50:01 PST
Date: Fri, 2 Dec 88 14:58:33 EST
From: Ian Horswill <IDH@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU
cc: "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-reply-to: Msg of Fri 2 Dec 88 08:59:36 +0200 from Jussi Opas <jho%hutcs.hut.fi at Forsythe.Stanford.EDU>
Message-ID: <497237.881202.IDH@AI.AI.MIT.EDU>
I got an old version running on lucid 3.0. It worked fairly well, but
I haven't tried it for several months.
-ian
∂05-Dec-88 1149 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 5 Dec 88 11:48:58 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA13303; Mon, 5 Dec 88 14:47:57 EST
From: mcvax!delphi!beppe@uunet.UU.NET
Received: by mcvax.cwi.nl via EUnet; Mon, 5 Dec 88 16:06:58 +0100 (MET)
Received: by cernvax.uucp (1.2/Ultrix2.0-B)
id AA01952; Mon, 5 Dec 88 13:41:04 +0100
Received: by delphi.uucp (3.2/SMI-3.2)
id AA06165; Mon, 5 Dec 88 11:39:07 +0100
Date: Mon, 5 Dec 88 11:24:18 MET
Subject: Re: Other-LISP-versions-of-CLUE
To: Jussi Opas <sun!Forsythe.Stanford.EDU!jho@hutcs.hut.fi>
Cc: cl-windows@sail.stanford.edu
Message-Id: <88/12/05 1124.910@delphi>
In-Reply-To: Jussi Opas's message of Fri, 2 Dec 88 085936 +0200
CLUE runs under Delphi Common LISP, which provides the necessary full
support for window streams. You can both read and write to a window
as a stream.
DELPHI Common Lisp (DCL) is an implementation of Common LISP, derived from
KCL, which includes a specially tuned version of CLX, a proprietary
implementation of CLOS, and a multithread facility for concurrency.
DCL is available on SUN, Apollo, Olivetti/ATT 386 PC and other Unix
workstations.
Beppe
-----
∂13-Dec-88 2122 CL-Windows-mailer Re: lookup-color deadlock
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 21:22:09 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA13152; Tue, 13 Dec 88 21:21:00 PST
Received: from sparky by franz (3.2/3.14)
id AA09734; Tue, 13 Dec 88 20:53:20 PST
Received: from localhost by sparky (4.0/3.14)
id AA06056; Tue, 13 Dec 88 20:51:19 PST
Return-Path: <sparky!jdi>
Message-Id: <8812140451.AA06056@sparky>
To: franz!home.csc.ti.com!oren
Cc: franz!sail.stanford.edu!cl-windows, franz!zermatt.lcs.mit.edu!bug-clx
Subject: Re: lookup-color deadlock
Date: Tue, 13 Dec 88 20:51:18 -0800
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Your message:
I think lookup-color should return nil if the color string isn't found.
It seems overly pedantic to require the programmer to find out that the
requested color doesn't exist by trapping name errors using handler-bind
...
I agree, returning NIL on name errors would be a nice feature.
It would be nice if open-font would do this too...
Would you like to add these features John?
- --------
Ugh. Not this year... :-)
I guess my first question then is why does the lookup-color request deadlock --
shouldn't wait-for-reply read the error and print it out? (It doesn't,
the process just sits in the wait-for-reply)
Looking at Xlib, its reply function returns 0 *without* calling XError
if it gets a NAME error on certain requests, an ALLOC or ACCESS error,
or a FONT error on query-font. So it would seem we could make
wait-for-reply take apart the error the way Xlib does, eat the error,
and return an "I snarfed this error" value.
Assuming it's possible to snarf the error and return some useful failure value
from (lookup-color, open-font, alloc-coloc, store-color, store-colors,
(did I miss any)), what should be returned? nil? Seems like people will
write code like:
(let ((color (xlib:lookup-color *default-colormap* "brownn")))
(setq red-val (xlib:color-red color)))
which will fail with an unhelpful bus error on conventional architectures (in
compiled code at high speed, low safety settings, your mileage may vary).
However, even with this problem I think it's better to return nil than to
signal an error. Is there an approval process for changes to the CLX
spec?
I'm CC'ing this letter to cl-windows to provoke some discussion.
-- John Irwin, Franz Inc. jdi%franz.uucp@ucbarpa.berkeley.edu
∂16-Dec-88 1304 CL-Windows-mailer CLX create-colormap question
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:04:10 PST
Received: by ti.com id AA20147; Fri, 16 Dec 88 15:03:01 CST
Received: from SSB by tilde id AA07297; Fri, 16 Dec 88 14:56:29 CST
Message-Id: <2807297822-11977269@SSB>
Sender: STENGER@SSB.csc.ti.com
Date: Fri, 16 Dec 88 14:57:02 CST
From: Dan Stenger <Stenger@tilde.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: CLX create-colormap question
Does anyone have any ideas on why the create-colormap function in CLX should
take a resource-id to specify the visual type for the colormap instead of a
visual-info structure? This question also relates to the
screen-root-visual, create-window, get-raw-image, and window-visual
functions which all accept or return a resource-id for visual types instead
of visual-info structures.
In general, anytime I see a resource-id being passed into or out of an
external CLX function I wonder if there is a design flaw. It seems as if
users of CLX should be interacting with the CLX structures and protected
from the actual resource-ids. Any opinions?
Dan Stenger
Texas Instruments
Computer Science Center
stenger@csc.ti.com
∂17-Dec-88 0928 CL-Windows-mailer Re: CLX create-colormap question
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Dec 88 09:27:55 PST
Received: by expo.lcs.mit.edu; Sat, 17 Dec 88 10:24:51 EST
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Message-Id: <8812171524.AA08829@EXPO.LCS.MIT.EDU>
To: Stenger@tilde.csc.ti.com
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX create-colormap question
In-Reply-To: Your message of Fri, 16 Dec 88 14:57:02 CST.
<2807297822-11977269@SSB>
Date: Sat, 17 Dec 88 10:24:50 EST
Does anyone have any ideas on why the create-colormap function in CLX should
take a resource-id to specify the visual type for the colormap instead of a
visual-info structure?
I don't think there was a particularly compelling reason. (BTW, it isn't
actually a *resource* id, it's just an id.) Is there a particularly
compelling reason for changing it at this point?
∂19-Dec-88 1816 CL-Windows-mailer Using .snf fonts
Received: from rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 19 Dec 88 18:16:22 PST
Received: from MCC.COM by rand.org; Mon, 19 Dec 88 17:21:53 PST
Received: from TLALOC.ACA.MCC.COM (TLALOC.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Mon 19 Dec 88 19:20:37-CST
Date: Mon, 19 Dec 88 19:20 CST
From: Mark A. Derthick <Mark.Derthick@MCC.COM>
Subject: Using .snf fonts
To: lispx@rand.org
Message-Id: <19881220012007.8.DERTHICK@TLALOC.ACA.MCC.COM>
Postal-Address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-Phone: (512) 338-3724
I'm trying to use a program which came with .snf files, but no corresponding
.bdf files. Is there a way to tell the Lispm to go directly to the .snf files?
Please respond to derthick@mcc.com because I don't subscribe to this list.
Thanks,
Mark Derthick
∂27-Dec-88 0825 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 27 Dec 88 08:25:18 PST
Return-Path: <elaine@starbase.mitre.org>
Received: by gateway.mitre.org (5.54/SMI-2.2)
id AA10206; Tue, 27 Dec 88 11:20:04 EST
Received: by starbase.mitre.org (4.0/SMI-4.0)
id AA05432; Tue, 27 Dec 88 11:23:44 EST
Date: Tue, 27 Dec 88 11:23:44 EST
From: elaine@starbase.mitre.org (Elaine Lusher)
Message-Id: <8812271623.AA05432@starbase.mitre.org>
To: IDH@AI.AI.MIT.EDU
Cc: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU,
"CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-Reply-To: Ian Horswill's message of Fri, 2 Dec 88 14:58:33 EST <497237.881202.IDH@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
I read your note mentioning that you had succeeded in getting clue to run
under lucid 3.0. If so, I would love to know how. I have tried to compile
clue on the Sun using Lucid CL 2.1.3, and got many errors (some of which
I fixed). I decided to pull out TI's implementation of CLOS and substitute
the latest PCL version instead. Still, I get errors simply compiling. CLUE
is littered with #+explorer statements, leading me to believe that lisp
machines probably have been tested, but I wonder if it even works on a SUN.
I have checked with one of the authors of CLUE, Sun sales types, and LUCID.
None of these people are familiar with CLUE on a SUN. The type of errors
I see (calls to the SI package in their version of CLOS, for example) lead
me to believe that it's never been tested for lucid. Perhaps part of my
problem is that we don't have lucid 3.0.
If you have succeeded in running CLUE, I would like to know what version (and
the specific configuration) you used. Thanks for any help you can give.
Elaine Lusher
MITRE Corp.
lusher@mitre.arpa
∂06-Jan-89 0935 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 09:35:04 PST
Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159449; Fri 6-Jan-89 12:32:47 EST
Date: Fri, 6 Jan 89 12:35 EST
From: Ian Horswill <idh@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: elaine@starbase.mitre.org, IDH@AI.AI.MIT.EDU
cc: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU, "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8812271623.AA05432@starbase.mitre.org>
Message-ID: <19890106173519.2.IAN@KAREN.AI.MIT.EDU>
Hmmm. I did it over the summer, so I don't remember what version of
CLUE I was using. I was using a Beta version of Lucid 3.0 and the
latest versions of PCL.
There were lots of problems. The #+explorer things weren't too bad, it
was when they didn't have #+'s in things, such as references to the tv
package that I had problems. CLUE also exercised many things in CLOS
which had not been very thoroughly tested in PCL, such as specializing
generic functions with quoted parameters. I spend a couple weeks trying
to figure out what CLUE was doing only to find out that PCL was doing
the wrong thing. Then I got to learn how PCL worked. I also had to do
some obnoxious hacking around with the I/O system in lucid so that it
would support CLOS instances as I/O streams, and so the reader would
support weird characters like #\Refresh. Oh, and I also had to do some
weird things to make the packages I was using which wanted the old
version of make-instance, etc. get the old version, and CLUE have the
new. There may have been other things, I had to do, I don't remember.
All in all, it was the least pleasant summer job of my life and did bad
things for my self-esteem. I spend so much time fixing CLX, PCL, and
CLOS that I got virtually no work done on the real project at hand.
I've been planning on trying to bring things back up this month so I'll
tell you if things still work or if they broke from bit rot over the
fall.
-ian
∂06-Jan-89 1121 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 11:20:36 PST
Received: by ti.com id AA02742; Fri, 6 Jan 89 13:19:09 CST
Received: from dsg by tilde id AA02852; Fri, 6 Jan 89 13:02:39 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 6 Jan 89 13:02:10 CST
Message-Id: <2809105143-355886@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 6 Jan 89 12:59:03 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Ian Horswill <idh@AI.AI.MIT.EDU>
Cc: clue-review@dsg.csc.ti.com, cl-windows@SAIL.STANFORD.EDU
Subject: Re: Other-LISP-versions-of-CLUE
In-Reply-To: Msg of Fri, 6 Jan 89 12:35 EST from Ian Horswill <idh@AI.AI.MIT.EDU>
> I did it over the summer, so I don't remember what version of
> CLUE I was using. I was using a Beta version of Lucid 3.0 and the
> latest versions of PCL.
Undoubtedly, this was CLUE 1.13. The latest CLUE is 1.15, shipped in September
with X11 R3. Nota bene: CLUE 1.15 *must* be used with R3 CLX.
> The #+explorer things weren't too bad, it
> was when they didn't have #+'s in things, such as references to the tv
> package that I had problems. ... I also had to do
> some obnoxious hacking around with the I/O system in lucid so that it
> would support CLOS instances as I/O streams, and so the reader would
> support weird characters like #\Refresh.
The CLUE spec doesn't make it altogether clear, but the implementation of
clue:interactive-stream is necessarily non-portable. That is, you've got to
integrate it in with your Lisp's stream implementation at a low level. The
interactive-stream code in the CLUE release is good for Explorers (natch) but
only an example for other environments.
This problem would be alleviated if there existed a standard generic function
protocol for implementing Common Lisp streams. This is a worthy task for X3J13.
> All in all, it was the least pleasant summer job of my life and did bad
> things for my self-esteem. I spend so much time fixing CLX, PCL, and
> CLOS that I got virtually no work done on the real project at hand.
This is most regrettable. On the bright side, most of the PCL integration
problems should disappear soon (if not already), as PCL is rapidly improving in
its reliability and its conformance with the CLOS spec. On the gloomy side,
no one has yet committed the energy to picking a good PCL rev and nailing down
the PCL/CLUE integration problem once and for all (where 2 weeks < all <
forever).
∂06-Jan-89 2209 CL-Windows-mailer Please add my name to your List
Received: from radar.nrl.navy.mil by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:09:39 PST
Received: by radar.nrl.navy.mil (5.9/4.7)
id AA02534; Sat, 7 Jan 89 00:58:29 EST
Message-Id: <8901070558.AA02534@radar.nrl.navy.mil>
Date: Sat 7 Jan 1989 00:23:19 EST
From: Scott Musman <musman@radar.nrl.navy.mil>
Subject: Please add my name to your List
To: cl-windows@sail.stanford.edu
I'm looking for some graphics tools or toolkits which run in
Common Lisp. My applications are not very complex, and mostly involve
image display, messing with colormaps and button pressing. I have
been able to implement some rudimentory routines using CLX running
X11.2 on a SUN3 using Lucid, but I am somewhat dissmayed at the amount
of work involved in just using CLX.
The only toolkit, which I presently know of is CLUE from TI.
While I have already scarfed, up the latest version, I have not yet
used it, or in fact tried to load it. It would be nice to know, before I
get too deeply entrenched, something about its stability, reliability
and what other alternatives there are to using it.
While the windows supplied with Lucid 3.0 on the SUN can
probably satisfy my present needs, I am currently running 2.1, because I
must rewrite the graphics routines before I can upgrade (due to space
limitations on my machine). What I am looking for is a longer range
solution. To this end, it would be nice to hear some speculations on
where LISP based window systems are headed.
Thanx
Scott
<musman@radar.nrl.navy.mil>
∂06-Jan-89 2247 CL-Windows-mailer Re: Other-LISP-versions-of-CLUE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 13:53:10 PST
Date: 6 Jan 89 13:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Other-LISP-versions-of-CLUE
In-reply-to: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>'s message of Fri, 6
Jan 89 12:59:03 CST
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: Ian Horswill <idh@AI.AI.MIT.EDU>, clue-review@dsg.csc.ti.com,
cl-windows@SAIL.STANFORD.EDU
Message-ID: <890106-135310-1059@Xerox>
Re: "This problem would be alleviated if there existed a standard generic
function
protocol for implementing Common Lisp streams. This is a worthy task for
X3J13."
I've looked for and have not yet found a volunteer willing to work on
writing up a proposal. Are you interested?
∂09-Jan-89 1203 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 12:03:47 PST
Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159860; Mon 9-Jan-89 14:59:39 EST
Date: Mon, 9 Jan 89 14:59 EST
From: Ian Horswill <idh@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: idh@AI.AI.MIT.EDU, elaine@starbase.mitre.org
cc: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU, "CLUE-REVIEW@DSG.CSC.TI.COM"@XX.LCS.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <19890106173519.2.IAN@KAREN.AI.MIT.EDU>
Message-ID: <19890109195955.1.IAN@KAREN.AI.MIT.EDU>
Gee, after looking over my previous message I think I ought to say that
CLUE did everything it was advertised to do very well, and I don't want
to bash either it or its implementation. I'm also quite amazed by how
well PCL works. My problems were due to my own over-ambitiousness, not
to defects in other people's software.
-ian
∂30-Jan-89 1233 CL-Windows-mailer Where to get CLUE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 30 Jan 89 12:33:36 PST
Received: by ti.com id AA26464; Mon, 30 Jan 89 14:32:47 CST
Received: from dsg by tilde id AA19686; Mon, 30 Jan 89 14:21:56 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 30 Jan 89 14:16:11 CST
Message-Id: <2811183400-1597073@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Mon, 30 Jan 89 14:16:40 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: clue-review@dsg.csc.ti.com
Cc: cl-windows@sail.stanford.edu
Subject: Where to get CLUE
For those of you who asked recently, here's how to use anonymous FTP to grab a
copy of CLUE 1.15.
Host: CSC.TI.COM
Internet address: 10.7.0.46
Directory: pub/clue.tar.Z
∂30-Jan-89 1434 CL-Windows-mailer Lisp Xperts' BOF
Received: from ti.com by SAIL.Stanford.EDU with TCP; 30 Jan 89 14:34:23 PST
Received: by ti.com id AA26927; Mon, 30 Jan 89 16:33:33 CST
Received: from dsg by tilde id AA22466; Mon, 30 Jan 89 16:20:20 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 30 Jan 89 16:17:54 CST
Message-Id: <2811190708-2036154@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Mon, 30 Jan 89 16:18:28 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: clue-review@dsg.csc.ti.com
Cc: cl-windows@sail.stanford.edu
Subject: Lisp Xperts' BOF
On Jan 24, during the X Technical Conference at MIT, about 48 persons met in a
birds-of-a-feather session for people interested in Lisp X programming tools --
CLX, CLUE, and (by indirection) CLOS. A show of hands indicated that the
participants were divided roughly equally between those who were currently using
CLX and those who were interested but inexperienced. CLX users were further
split approximately equally between application programmers and toolkit
programmers. Almost no one present was currently using CLUE.
Someone asked if CLX was an X Consortium standard. Not quite, explained LaMott
Oren. According to LaMott, the main obstacle remaining is the lack of
documentation, but Mike Myjak of TI is now working to remedy this problem. The
latest version of Myjak's CLX manual should be available soon via anonymous FTP.
I spoke for a few minutes to outline some of the future plans for CLUE. The
next available version of CLUE should appear in Q2. New features will include
shell contacts, constraint resources, contact reparenting, and defaction
cleanup. In Q3, CLUE 2.01 will introduce built-in contact classes which
implement a CL binding for the Consortium-standard "core components". Suzanne
McBride, who is currently working on the implementation of CLUE core components,
gave a brief overview of this Consortium project.
BOF participants received a survey form asking about their usage of CLX, CLUE,
and CLOS. Response to the survey was very light -- about 20% -- but the results
are shown below.
CLX -------------------------------------------------------------------------
Responding: 10
Currently using: 5
Currently planning to use: 4
Currently planning to implement (!!): 1
Which implementation:
R3 4
R2 2
Which Common Lisp:
Lucid 4
KCL 1
Franz Allegro 3.0 1
CMU Common Lisp 1
Vax Lisp 1
Sun Common Lisp 1
Which computer:
Sun 3 4
Sun 4 3
HP 9000/350 2
IBM PC/RT 1
Apollo 1
Vax 1
Things I like:
Easy
Availability
Reliable
Good interface
Things I want fixed:
Event processing: need more raw events
Better documentation (4)
wm-hints: use atoms/strings, etc.
Multitasking bugs: process locking missing in some places
Annoyance: multiple layers of macros make source hard to
understand/debug
event-case :discard-p should default to T
CLUE ------------------------------------------------------------------------
Responding: 4
Currently using: 0
Currently planning to use: 4
Which implementation:
TI public 1
Which Common Lisp:
Lucid 2
Vax Lisp 1
Sun Common Lisp 1
Which computer:
Sun 3 1
Sun 4 2
Apollo 1
Vax 1
Things I like:
Things I want fixed:
Better documentation
CLOS ------------------------------------------------------------------------
Responding: 5
Currently using: 2
Currently planning to use: 2
Have used: 1
Which implementation:
PCL 4
Which Common Lisp:
Lucid 2
Franz Allegro 3.0 1
CMU Common Lisp 1
Vax Lisp 1
Which computer:
Sun 4 2
Sun 3 1
IBM PC/RT 1
HP 9000/350 1
Vax 1
Things I like:
Reasonable design
Portable interface
Things I want fixed:
Too slow 3
∂31-Jan-89 1202 CL-Windows-mailer Help!!!!
Received: from EN-C06.Prime.COM by SAIL.Stanford.EDU with TCP; 31 Jan 89 12:02:07 PST
Received: from NET.Prime.COM by EN-C06.Prime.COM; 31 Jan 89 15:01:24 EST
Received: from primerd.prime.com by NET.Prime.COM; 31 Jan 89 14:59:08 EST
Received: from zaphod.prime.com by primerd.prime.com (4.0/SMI-4.0)
id AA29980; Tue, 31 Jan 89 14:57:22 EST
Received: by zaphod.prime.com (4.0/SMI-4.0)
id AA04106; Tue, 31 Jan 89 14:58:04 EST
Date: Tue, 31 Jan 89 14:58:04 EST
From: doug@zaphod.prime.com (Douglas Rand)
Message-Id: <8901311958.AA04106@zaphod.prime.com>
To: cl-windows@sail.stanford.edu
Subject: Help!!!!
In using CLX I've encountered a real problem. When I'm trying to choose
from a popup-menu I want events handled by a recursive level of a normally
top level event handling loop. The problem is that under LCL 3.0 this
apparently happens on a separate stack from the invoker of the new event
loop. This seems to be related to a process locking that occurs when
CLX calls holding-lock. The problem is that a throw from the menu handling
functions finds no corresponding catch (which is in the caller's frame).
So:
1) Am I doing this the wrong way? (It worked under the older Lucid CL)
2) Is there a simple change I can make to cause it to work this way?
3) Should I disable the process stuff in CLX?
Cheers,
(and confused)
Doug (doug@zaphod.prime.com)
∂31-Jan-89 1226 CL-Windows-mailer Help!!!!
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Jan 89 12:26:25 PST
Received: from boston-harbor ([192.9.202.1]) by heavens-gate.lucid.com id AA00347g; Tue, 31 Jan 89 12:20:24 PST
Received: by boston-harbor id AA00163g; Tue, 31 Jan 89 15:25:16 EST
Date: Tue, 31 Jan 89 15:25:16 EST
From: Judy Anderson <yduJ@lucid.com>
Message-Id: <8901312025.AA00163@boston-harbor>
To: doug@zaphod.prime.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Douglas Rand's message of Tue, 31 Jan 89 14:58:04 EST <8901311958.AA04106@zaphod.prime.com>
Subject: Help!!!!
I would recommend strongly against removing the process stuff from
CLX, unless you really want to lose in new and exciting ways. Which
release of CLX are you using? If you are using R2, do you have the
process locking patches I sent out a while ago? I did find that my
original patches weren't enough, and more places require process
locking. (However, my current set has too many; now I get occasional
deadlocks...)
I don't think I understand the exact nature of your bug well enough to
advise you on it; it sounds pretty odd. Are you doing anything funny
with interrupts? Lucid multitasking?
yduJ (Judy Anderson)
Lucid East
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
∂07-Feb-89 0819 CL-Windows-mailer I/O generic functions
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 08:19:17 PST
Received: by ti.com id AA26003; Tue, 7 Feb 89 10:18:11 CST
Received: from Kelvin by tilde id AA12256; Tue, 7 Feb 89 10:04:42 CST
Message-Id: <2811859381-15005799@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 7 Feb 89 10:03:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
Subject: I/O generic functions
It would be nice if the Common Lisp input and output functions could be
defined in terms of primitives which are generic functions so that users
would have a portable way to create their own streams by defining classes
and methods and have those streams be acceptable to the standard I/O
functions. This would be especially valuable for supporting the
development of window systems for Common Lisp.
It may be too late to include this in the standard, but it would be useful
to at least establish some common practice guidelines to avoid unnecessary
incompatibilities between implementations that will want to do something
like this anyway. In order to get some discussion started, following is a
preliminary outline showing what might be done.
Shown below are a few primitive generic functions which would need to have
methods defined for each stream class, and a few more which the user could
either define himself, or use a default method provided by an included
class. [This does not yet include non-character streams.] Finally, it
shows how the I/O functions of CLtL could be implemented using these
generic functions. Note that the Common Lisp I/O functions themselves
cannot be made into generic functions because in nearly every case the
stream argument is optional and thus can't be specialized. Note also that
the existing generic function PRINT-OBJECT is a higher-level operation
since even when the first argument is just a character or string, it still
needs to format the output in accordance with *PRINT-ESCAPE*.
;;;; Implementation of Common Lisp I/O routines using generic functions
;;; Generic functions for primitive input operations that must be defined for each stream.
(defgeneric STREAM-READ-CHAR (stream &optional eof-error-p eof-value))
(defgeneric STREAM-UNREAD-CHAR (stream character))
(defgeneric STREAM-LISTEN (stream))
;;; Other input operations which can be defaulted by including the following class.
(defclass DEFAULT-INPUT-STREAM (stream) ())
(defgeneric STREAM-READ-CHAR-NO-HANG (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional eof-error-p eof-value)
(stream-read-char stream eof-error-p eof-value)))
(defgeneric STREAM-PEEK-CHAR (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional (eof-error-p t) eof-value)
(let ((character (stream-read-char stream eof-error-p eof-value)))
(unless (eql character eof-value)
(stream-unread-char stream character))
character)))
(defgeneric STREAM-READ-LINE (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional eof-error-p eof-value)
(let ((line (make-array 60 :element-type 'string-char :fill-pointer 0)))
(loop (let ((character (stream-read-char stream eof-error-p eof-value)))
(if (eql character eof-value)
(return (values line eof-value))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line))))))))
(defgeneric STREAM-CLEAR-INPUT (stream)
(:method ((stream default-input-stream)) nil))
(defgeneric STREAM-CLOSE (stream))
(defmethod STREAM-CLOSE ((stream default-input-stream)) nil) ; or is it T?
;;; Generic functions for primitive output operations that must be defined for each stream.
(defgeneric STREAM-WRITE-CHAR (stream character))
(defgeneric STREAM-START-LINE-P (stream)) ; returns true if positioned at beginning of line.
(defgeneric STREAM-LINE-COLUMN (stream)) ; returns current column number if meaningful, else nil
;;; Other output operations which can be defaulted by including the following class.
(defclass DEFAULT-OUTPUT-STREAM (stream) ())
(defgeneric STREAM-WRITE-STRING (stream string &optional start end)
(:method ((stream default-output-stream) string &optional (start 0) end)
(let ((limit (or end (length string))))
(do ((i start (1+ i)))
((< i limit))
(stream-write-char stream (char string i))))
string))
(defgeneric STREAM-TERPRI (stream)
(:method ((stream default-output-stream))
(stream-write-char stream #\newline)
nil))
(defgeneric STREAM-FRESH-LINE (stream)
(:method ((stream default-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t))))
(defgeneric STREAM-FINISH-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
(defgeneric STREAM-FORCE-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
(defgeneric STREAM-CLEAR-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
;; useful for pprint and format ~T
(defgeneric STREAM-ADVANCE-TO-COLUMN (stream column)
(:method ((stream default-output-stream) column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column))
(stream-write-char stream #\space))
t))))
(defmethod STREAM-CLOSE ((stream default-output-stream)) nil)
;;; Internal helper functions [not intended to be standardized]
(proclaim '(inline decode-read-arg))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(proclaim '(inline decode-print-arg))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
;;; Common Lisp query functions
(defgeneric INPUT-STREAM-P (stream)
(:method ((stream default-input-stream)) t)
(:method ((stream default-output-stream)) nil))
(defgeneric OUTPUT-STREAM-P (stream)
(:method ((stream default-output-stream)) t)
(:method ((stream default-input-stream)) nil))
(defgeneric STREAM-ELEMENT-TYPE (stream)
(:method ((stream default-output-stream)) 'character)
(:method ((stream default-input-stream)) 'character))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; This appears to have been a mistake in CLtL.
(stream-read-char (decode-read-arg input-stream) eof-errorp eof-value))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(stream-peek-char stream eof-errorp eof-value)
...)))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t) eof-value recursive-p)
(declare (ignore recursive-p))
(stream-read-line (decode-read-arg input-stream) eof-error-p eof-value))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p))
(stream-read-char-no-hang (decode-read-arg input-stream) eof-errorp eof-value))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
∂07-Feb-89 1016 Common-Lisp-Object-System-mailer Re: I/O generic functions
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:15:49 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 7 Feb 89 10:14:20 pst
Received: from loopback by hplwhh.HPL.HP.COM; Tue, 7 Feb 89 10:13:10 pst
Full-Name: Warren Harris
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com,
CL-Cleanup@SAIL.Stanford.edu
Subject: Re: I/O generic functions
In-Reply-To: Your message of "Tue, 07 Feb 89 10:03:01 CST."
<2811859381-15005799@Kelvin>
Date: Tue, 07 Feb 89 10:13:06 PST
Message-Id: <26670.602878386@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
I just wanted to point out that there is an entire section of Sonya Keene's
book "Object Oriented Programming in Common Lisp" dedicated to an
implementation of streams as objects. Perhaps this implementation would be
a good starting point for a formal proposal on generic i/o routines. Can
anyone summarize what might be missing in a "real" implementation?
Warren
∂07-Feb-89 1033 Common-Lisp-Object-System-mailer Re: I/O generic functions
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:33:15 PST
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534937; Tue 7-Feb-89 13:29:52 EST
Date: Tue, 7 Feb 89 13:28 EST
From: Sonya Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: I/O generic functions
To: harris%hplwhh@hplabs.hp.com
cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com, CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: <26670.602878386@hplwhh>
Message-ID: <19890207182849.1.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: Tue, 07 Feb 89 10:13:06 PST
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
I just wanted to point out that there is an entire section of Sonya Keene's
book "Object Oriented Programming in Common Lisp" dedicated to an
implementation of streams as objects. Perhaps this implementation would be
a good starting point for a formal proposal on generic i/o routines. Can
anyone summarize what might be missing in a "real" implementation?
Warren
I'd like to recommend against this idea! My goals in developing that
example for my book were very different from your goals in designing a
real stream implementation. I wanted to keep the example as simple as
possible, while illustrating a lot of the sharing that can happen when
streams are done in an object-oriented way. My main interest was not
in doing streams the right way, but just to find something that could
illustrate good modularity and inheritance.
I agree that streams are ripe for an object-oriented design, but your
design should probably start from scratch. Actually, there are some
object-oriented streams implementations out there (Symbolics has one,
and there must be others), and you could look into those as a starting
point.
Sonya
∂07-Feb-89 1821 CL-Windows-mailer CLX and ICCCM
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 18:20:59 PST
Received: by ti.com id AA28580; Tue, 7 Feb 89 20:19:54 CST
Received: from dsg by tilde id AA25645; Tue, 7 Feb 89 20:05:15 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 7 Feb 89 20:04:04 CST
Message-Id: <2811895411-1805738@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 7 Feb 89 20:03:31 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: CLX and ICCCM
Here is a proposal for changes to CLX to support the draft standard Interclient
Communications Conventions Manual. Comments and suggestions welcome. All changes
are summarized below.
1. wm-class replaces get-wm-class, for greater consistency. Unfortunately,
set-wm-class remains, but only temporarily, since Common Lisp will soon
define multiple value setf's.
2. wm-hints, wm-normal-hints: an optional argument to store the returned
property value structure is added.
3. transient-for renamed to wm-transient-for in order to be consistent with the
other property functions and with the property name itself.
4. New property functions added: wm-colormap-windows, wm-protocols, wm-state.
5. wm-icon-size replaces icon-sizes. A new wm-icon-size structure is defined
for the value of this property.
6. wm-icon-name, wm-name, wm-client-machine, wm-command: These return a
new second value giving the type atom for the string encoding. setf forms
also accept new keyword arguments for type, translate, and size.
7. wm-command now returns/stores a single string value, instead of a
list encoded as a sequence of strings. This interface is more correct given
that the interpretation of this property is system-dependent.
8. wm-hints structure: The type of initial-state is changed to (member :normal
:iconic :withdrawn).
9. wm-size-hints structure: The default values of user-specified-size/position-p
are changed to nil, in order to better reflect the typical case. x, y, width,
height slots have been removed. New slots are added for base-width,
base-height, and gravity
;;;----------------------------------------------------------------------------+
;;; |
;;; Window Manager Properties |
;;; |
;;;----------------------------------------------------------------------------+
(defun wm-class (window)
"Return the two string values from the :WM_CLASS property of the window:
the application resource name and the application resource class."
(declare (type window window))
(declare-values name class))
(defun set-wm-class (window name class)
"Set the :WM_CLASS property of the window with the given application resource
name and application resource class name."
(declare (type window window)
(type stringable name class))
(declare-values name class))
(defun wm-colormap-windows (window)
"Return the list of windows from the :WM_COLORMAP_WINDOWS property
of the window."
(declare (type window window))
(declare-values list))
(defsetf wm-colormap-windows (window) (sequence)
"Store a sequence of windows in the :WM_COLORMAP_WINDOWS property
of the window."
(declare (type window window)
(type (sequence window) sequence))
(declare-values sequence))
(defun wm-hints (window &optional structure)
"Return the wm-hints structure from the :WM_HINTS property
of the window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-hints structure))
(declare-values structure))
(defsetf wm-hints (window) (hints)
"Store the wm-hints structure in the :WM_HINTS property
of the window."
(declare (type window window)
(type wm-hints hints))
(declare-values hints))
(defstruct wm-hints
(input nil :type (or null (member :off :on)))
(initial-state nil :type (or null (member :normal :iconic :withdrawn)))
(icon-pixmap nil :type (or null pixmap))
(icon-window nil :type (or null window))
(icon-x nil :type (or null card16))
(icon-y nil :type (or null card16))
(icon-mask nil :type (or null pixmap))
(window-group nil :type (or null resource-id))
(flags 0 :type card32) ;; Extension-hook
)
(defun wm-icon-name (window)
"Return the array of characters from the :WM_ICON_NAME property of the window.
The second value returned is the type atom indicating the character encoding
of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-icon-name (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_ICON_NAME property of the window
using the given type atom to indicate the character encoding of the sequence.
The translate function is used to transform elements of the name sequence
into octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-icon-size (window &optional structure)
"Return the wm-icon-size structure from the :WM_ICON_SIZE property
of the (root) window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-icon-size structure))
(declare-values structure))
(defstruct wm-icon-size
(min-width nil :type (or null card16))
(min-height nil :type (or null card16))
(max-width nil :type (or null card16))
(max-height nil :type (or null card16))
(width-inc nil :type (or null card16))
(height-inc nil :type (or null card16)))
(defun wm-name (window)
"Return the array of characters from the :WM_NAME property of the window. The
second value returned is the type atom indicating the character
encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-name (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_NAME property of the window, using
the given type atom to indicate the character encoding of the sequence. The
translate function is used to transform elements of the name sequence into
octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-normal-hints (window &optional structure)
"Return the wm-size-hints structure from the :WM_NORMAL_HINTS property
of the window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-size-hints structure))
(declare-values structure))
(defsetf wm-normal-hints (window) (hints)
"Store the wm-size-hints structure in the :WM_NORMAL_HINTS property
of the window."
(declare (type window window)
(type wm-size-hints hints))
(declare-values hints))
(defstruct wm-size-hints
(user-specified-position-p nil :type boolean)
(user-specified-size-p nil :type boolean)
(min-width nil :type (or null card16))
(min-height nil :type (or null card16))
(max-width nil :type (or null card16))
(max-height nil :type (or null card16))
(width-inc nil :type (or null card16))
(height-inc nil :type (or null card16))
(min-aspect nil :type (or null number))
(max-aspect nil :type (or null number))
(base-width nil :type (or null card16))
(base-height nil :type (or null card16))
(gravity nil :type win-gravity))
(defun wm-protocols (window)
"Return the list of atoms from the :WM_PROTOCOLS property of the window. "
(declare (type window window))
(declare-values list))
(defsetf wm-protocols (window) (sequence)
"Store a sequence of atoms in the :WM_PROTOCOLS property of the window.
Standard atoms are any of :wm_take_focus, :wm_save_yourself, or
:wm_delete_window."
(declare (type window window)
(type sequence sequence))
(declare-values sequence))
(defun wm-state (window)
"Return the current window-manager state of the window from its :WM_STATE property.
The return value is either :normal, :iconic, or :withdrawn, or an integer
specifiying a window-manager-dependent state."
(declare (type window window))
(declare-values state))
(defsetf wm-state (window &optional current-state) (new-state)
"Change the current window-manager state of the window. If the current-state
is omitted and the new-state is :iconic, then the current state is assumed
to be :normal."
(declare (type window window)
(type (member :normal :iconic :withdrawn) new-state current-state))
(declare-values new-state))
(defun wm-transient-for (window)
"Return the window object in the :WM_TRANSIENT_FOR property of the window."
(declare (type window window))
(declare-values transient-for))
(defsetf wm-transient-for (window) (transient-for)
"Store a window object in the :WM_TRANSIENT_FOR property of the window."
(declare (type window window transient-for))
(declare-values transient-for))
;;;----------------------------------------------------------------------------+
;;; |
;;; Session Manager Properties |
;;; |
;;;----------------------------------------------------------------------------+
(defun wm-client-machine (window)
"Return the array of characters from the :WM_CLIENT_MACHINE property
of the window. The second value returned is the type atom indicating the
character encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-client-machine (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_CLIENT_MACHINE property
of the window, using the given type atom to indicate the character encoding
of the sequence. The translate function is used to transform elements of the
name sequence into octets. The size defines the element size of the dst
buffer used by translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-command (window)
"Return the array of characters from the :WM_COMMAND property
of the window. The second value returned is the type atom indicating the
character
encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-command (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_COMMAND property of the window,
using the given type atom to indicate the character encoding of the sequence.
The translate function is used to transform elements of the name sequence
into octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
∂07-Feb-89 2005 CL-Windows-mailer CLX and ICCCM
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 18:20:59 PST
Received: by ti.com id AA28580; Tue, 7 Feb 89 20:19:54 CST
Received: from dsg by tilde id AA25645; Tue, 7 Feb 89 20:05:15 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 7 Feb 89 20:04:04 CST
Message-Id: <2811895411-1805738@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 7 Feb 89 20:03:31 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: CLX and ICCCM
Here is a proposal for changes to CLX to support the draft standard Interclient
Communications Conventions Manual. Comments and suggestions welcome. All changes
are summarized below.
1. wm-class replaces get-wm-class, for greater consistency. Unfortunately,
set-wm-class remains, but only temporarily, since Common Lisp will soon
define multiple value setf's.
2. wm-hints, wm-normal-hints: an optional argument to store the returned
property value structure is added.
3. transient-for renamed to wm-transient-for in order to be consistent with the
other property functions and with the property name itself.
4. New property functions added: wm-colormap-windows, wm-protocols, wm-state.
5. wm-icon-size replaces icon-sizes. A new wm-icon-size structure is defined
for the value of this property.
6. wm-icon-name, wm-name, wm-client-machine, wm-command: These return a
new second value giving the type atom for the string encoding. setf forms
also accept new keyword arguments for type, translate, and size.
7. wm-command now returns/stores a single string value, instead of a
list encoded as a sequence of strings. This interface is more correct given
that the interpretation of this property is system-dependent.
8. wm-hints structure: The type of initial-state is changed to (member :normal
:iconic :withdrawn).
9. wm-size-hints structure: The default values of user-specified-size/position-p
are changed to nil, in order to better reflect the typical case. x, y, width,
height slots have been removed. New slots are added for base-width,
base-height, and gravity
;;;----------------------------------------------------------------------------+
;;; |
;;; Window Manager Properties |
;;; |
;;;----------------------------------------------------------------------------+
(defun wm-class (window)
"Return the two string values from the :WM_CLASS property of the window:
the application resource name and the application resource class."
(declare (type window window))
(declare-values name class))
(defun set-wm-class (window name class)
"Set the :WM_CLASS property of the window with the given application resource
name and application resource class name."
(declare (type window window)
(type stringable name class))
(declare-values name class))
(defun wm-colormap-windows (window)
"Return the list of windows from the :WM_COLORMAP_WINDOWS property
of the window."
(declare (type window window))
(declare-values list))
(defsetf wm-colormap-windows (window) (sequence)
"Store a sequence of windows in the :WM_COLORMAP_WINDOWS property
of the window."
(declare (type window window)
(type (sequence window) sequence))
(declare-values sequence))
(defun wm-hints (window &optional structure)
"Return the wm-hints structure from the :WM_HINTS property
of the window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-hints structure))
(declare-values structure))
(defsetf wm-hints (window) (hints)
"Store the wm-hints structure in the :WM_HINTS property
of the window."
(declare (type window window)
(type wm-hints hints))
(declare-values hints))
(defstruct wm-hints
(input nil :type (or null (member :off :on)))
(initial-state nil :type (or null (member :normal :iconic :withdrawn)))
(icon-pixmap nil :type (or null pixmap))
(icon-window nil :type (or null window))
(icon-x nil :type (or null card16))
(icon-y nil :type (or null card16))
(icon-mask nil :type (or null pixmap))
(window-group nil :type (or null resource-id))
(flags 0 :type card32) ;; Extension-hook
)
(defun wm-icon-name (window)
"Return the array of characters from the :WM_ICON_NAME property of the window.
The second value returned is the type atom indicating the character encoding
of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-icon-name (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_ICON_NAME property of the window
using the given type atom to indicate the character encoding of the sequence.
The translate function is used to transform elements of the name sequence
into octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-icon-size (window &optional structure)
"Return the wm-icon-size structure from the :WM_ICON_SIZE property
of the (root) window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-icon-size structure))
(declare-values structure))
(defstruct wm-icon-size
(min-width nil :type (or null card16))
(min-height nil :type (or null card16))
(max-width nil :type (or null card16))
(max-height nil :type (or null card16))
(width-inc nil :type (or null card16))
(height-inc nil :type (or null card16)))
(defun wm-name (window)
"Return the array of characters from the :WM_NAME property of the window. The
second value returned is the type atom indicating the character
encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-name (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_NAME property of the window, using
the given type atom to indicate the character encoding of the sequence. The
translate function is used to transform elements of the name sequence into
octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-normal-hints (window &optional structure)
"Return the wm-size-hints structure from the :WM_NORMAL_HINTS property
of the window. If a non-nil structure is given, then it is used
to store the return value; otherwise, a new structure is
created and returned."
(declare (type window window)
(type wm-size-hints structure))
(declare-values structure))
(defsetf wm-normal-hints (window) (hints)
"Store the wm-size-hints structure in the :WM_NORMAL_HINTS property
of the window."
(declare (type window window)
(type wm-size-hints hints))
(declare-values hints))
(defstruct wm-size-hints
(user-specified-position-p nil :type boolean)
(user-specified-size-p nil :type boolean)
(min-width nil :type (or null card16))
(min-height nil :type (or null card16))
(max-width nil :type (or null card16))
(max-height nil :type (or null card16))
(width-inc nil :type (or null card16))
(height-inc nil :type (or null card16))
(min-aspect nil :type (or null number))
(max-aspect nil :type (or null number))
(base-width nil :type (or null card16))
(base-height nil :type (or null card16))
(gravity nil :type win-gravity))
(defun wm-protocols (window)
"Return the list of atoms from the :WM_PROTOCOLS property of the window. "
(declare (type window window))
(declare-values list))
(defsetf wm-protocols (window) (sequence)
"Store a sequence of atoms in the :WM_PROTOCOLS property of the window.
Standard atoms are any of :wm_take_focus, :wm_save_yourself, or
:wm_delete_window."
(declare (type window window)
(type sequence sequence))
(declare-values sequence))
(defun wm-state (window)
"Return the current window-manager state of the window from its :WM_STATE property.
The return value is either :normal, :iconic, or :withdrawn, or an integer
specifiying a window-manager-dependent state."
(declare (type window window))
(declare-values state))
(defsetf wm-state (window &optional current-state) (new-state)
"Change the current window-manager state of the window. If the current-state
is omitted and the new-state is :iconic, then the current state is assumed
to be :normal."
(declare (type window window)
(type (member :normal :iconic :withdrawn) new-state current-state))
(declare-values new-state))
(defun wm-transient-for (window)
"Return the window object in the :WM_TRANSIENT_FOR property of the window."
(declare (type window window))
(declare-values transient-for))
(defsetf wm-transient-for (window) (transient-for)
"Store a window object in the :WM_TRANSIENT_FOR property of the window."
(declare (type window window transient-for))
(declare-values transient-for))
;;;----------------------------------------------------------------------------+
;;; |
;;; Session Manager Properties |
;;; |
;;;----------------------------------------------------------------------------+
(defun wm-client-machine (window)
"Return the array of characters from the :WM_CLIENT_MACHINE property
of the window. The second value returned is the type atom indicating the
character encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-client-machine (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_CLIENT_MACHINE property
of the window, using the given type atom to indicate the character encoding
of the sequence. The translate function is used to transform elements of the
name sequence into octets. The size defines the element size of the dst
buffer used by translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
(defun wm-command (window)
"Return the array of characters from the :WM_COMMAND property
of the window. The second value returned is the type atom indicating the
character
encoding of the array."
(declare (type window window))
(declare-values array type))
(defsetf wm-command (window &key (type :string) translate (size 8)) (name)
"Set the sequence of characters in the :WM_COMMAND property of the window,
using the given type atom to indicate the character encoding of the sequence.
The translate function is used to transform elements of the name sequence
into octets. The size defines the element size of the dst buffer used by
translate."
(declare (type window window)
(type (or symbol sequence) name)
(type translate translate)
(type index-size size))
(declare-values name type))
∂07-Feb-89 2005 CL-Cleanup-mailer I/O generic functions
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 7 Feb 89 19:39:53 PST
Received: from OWL.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230; Tue 7-Feb-89 22:03:09 EST
Date: Tue, 7 Feb 89 22:02 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: I/O generic functions
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@SAIL.Stanford.edu, Common-Lisp-Object-System@SAIL.Stanford.edu,
CL-Windows@SAIL.Stanford.edu, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
In-Reply-To: <2811859381-15005799@Kelvin>
Message-ID: <19890208030248.1.MMCM@OWL.SCRC.Symbolics.COM>
This is the right sort of start. I have a few observations which are
not meant to be comprehensive. They might help stimulate further
careful design.
STREAM-LISTEN is actually not mandatory: you can implement it using
READ-CHAR-NO-HANG and UNREAD-CHAR.
If people are going to start defining well behaved streams, some
protocols need to be firmed up. For instance, if LISTEN is true, must
READ-CHAR-NO-HANG return a character? Or is it only that
READ-CHAR-NO-HANG returns a character or clears the LISTEN condition?
You can see the difference in the behavior of an encapsulated stream
with escape characters. In the one case, LISTEN can just do LISTEN on
the inside stream, which is presumably fast (e.g. checks some network
buffer pointers). If the buffer contains only the start of an escape
sequence, READ-CHAR-NO-HANG will still not return a character. In the
other case, LISTEN must run the entire decoding machinery right away and
unread any character it produces. The key decision is whether you want
LISTEN to be complete or efficient.
Wouldn't it be better to have just one centralized implementation of
eof-error-p eof-value handling? The internal stream methods could obey
just one protocol for returning EOF which the outer would process
independently.
∂09-Feb-89 1135 CL-Windows-mailer Patches for CLX under Lucid 3.0 and X11R2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 11:35:46 PST
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA02105g; Thu, 9 Feb 89 11:25:01 PST
Received: by rainbow-warrior id AA05567g; Thu, 9 Feb 89 11:27:59 PST
Date: Thu, 9 Feb 89 11:27:59 PST
From: Judy Anderson <yduJ@lucid.com>
Message-Id: <8902091927.AA05567@rainbow-warrior>
To: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu,
xpert@athena.mit.edu
Subject: Patches for CLX under Lucid 3.0 and X11R2
The following diffs are for release TWO (sorry, we've been in a
tearing hurry and haven't used release three yet) of X11 CLX, running
under Lucid 3.0. They assume you have applied my previous patches
(sent out to bug-clx only several months ago). There are two purposes
in these patches: 1: adding several places where more process locking
is required to prevent "Received a reply when none was expected"
errors, and 2: I/O speedups. The file dependent.l is the one directed
towards I/O speedups, the rest are process locking. I hope to start
using R3 soon and send out a message saying either "the same patches
will work" or "here's a new set for R3". However, since announcing at
the X conference that I had changes to CLX I've been being deluged
with fan mail asking for the changes, so here they are, a bit early
and only guaranteed for R2. The I/O speedups rely on Lucid's 3.0 I/O
system, which is incompatible with Lucid 2.1, so all of these hacks
are under #+LCL3.0.
yduJ (Judy Anderson)
Lucid East
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
(415)329-8400x4500
---------------------------------------------------------------------------
*** lib/CLX/dependent.l Fri Oct 21 22:40:11 1988
--- lib/LUCID-CLX/dependent.lisp Thu Feb 9 10:44:32 1989
***************
*** 428,437 ****
(defun radians->int16 (value)
;; Short floats are good enough
! (declare (type float value))
(declare-values int16)
(declare-buffun)
! (the int16 (identity (round (* value 180.0s0 64.0s0) #.(coerce pi 'short-float)))))
(defun int16->radians (value)
;; Short floats are good enough
--- 428,439 ----
(defun radians->int16 (value)
;; Short floats are good enough
! ;; Note that this gets called with integer zero sometimes and not all
! ;; implementations will have integer zero and float zero the same... --yduJ
! ; (declare (type float value))
(declare-values int16)
(declare-buffun)
! (the int16 (identity (round (* (float value) 180.0s0 64.0s0) #.(coerce pi 'short-float)))))
(defun int16->radians (value)
;; Short floats are good enough
***************
*** 886,897 ****
(minusp
(c-read-bytes fd vector start end))))))))))
;;; WARNING:
;;; CLX performance will suffer if your lisp uses read-byte for
;;; receiving all data from the X Window System server.
;;; You are encouraged to write a specialized version of
;;; buffer-read-default that does block transfers.
! #-(or symbolics-3600 explorer excl)
(defmacro CL-read-bytes (stream vector start end)
`(do* ((i ,start (index+ i 1))
(c nil))
--- 888,963 ----
(minusp
(c-read-bytes fd vector start end))))))))))
+ #+lcl3.0
+ (defmacro fast-read-bytes (stream vector start end)
+ `(do* ((i ,start (index+ i 1))
+ (c nil))
+ ((index>= i ,end) nil)
+ (declare (type array-index i)
+ (type (or null card8) c))
+ (setq c (lcl:fast-read-byte ,stream (unsigned-byte 8) nil nil))
+ (if c
+ (setf (aref ,vector i) c)
+ (return t))))
+
+ #+lcl3.0
+ (defmacro extract-underlying-stream (stream display direction)
+ ;;;Our job is to quickly get at the underlying stream for this display's
+ ;;;input stream structure.
+ `(let ((pair (assoc ,direction (display-plist ,display))))
+ (if pair (second pair)
+ (progn
+ (push (list ,direction
+ (lucid::underlying-stream ,stream ,direction))
+ (display-plist ,display))
+ (second (assoc ,direction (display-plist ,display)))))))
+
+ #+lcl3.0
+ (defun buffer-read-default (display vector start end timeout)
+ ;;Note that LISTEN must still be done on "slow stream" or the I/O system
+ ;;gets confused. But reading should be done from "fast stream" for speed.
+ ;;We inhibit scheduling when reading because there seem to be races in
+ ;;Lucid's multitasking implementation.
+ (declare (type display display)
+ (type buffer-bytes vector)
+ (type array-index start end)
+ (type (or null number) timeout)
+ (optimize (speed 3)
+ (safety 0)))
+ (let* ((stream (display-input-stream display))
+ (fast-stream (extract-underlying-stream stream display :input)))
+ (cond ((or (null timeout)
+ (listen stream))
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ nil) ;return NIL, it expects that
+ ((or (minusp timeout) (zerop timeout))
+ ;;negative timeout means try once, Jerry's hack. Zerop seems
+ ;;to *also* mean try once; don't understand why Jerry wanted -1.
+ (if (listen stream)
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ :timeout))
+ (timeout ;otherwise we have a bona-fide timeout on our hands which
+ ;we should wait for.
+ (let ((input-appeared
+ (lucid::waiting-for-input-from-stream fast-stream
+ (lucid::with-io-unlocked
+ (lcl:process-wait-with-timeout
+ "Waiting for CLX server response"
+ timeout #'listen stream)))))
+ (if input-appeared
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ :timeout))))))
+
+
;;; WARNING:
;;; CLX performance will suffer if your lisp uses read-byte for
;;; receiving all data from the X Window System server.
;;; You are encouraged to write a specialized version of
;;; buffer-read-default that does block transfers.
! #-(or symbolics-3600 explorer excl lcl3.0)
(defmacro CL-read-bytes (stream vector start end)
`(do* ((i ,start (index+ i 1))
(c nil))
***************
*** 904,913 ****
(return t))))
;; Poll for input every *buffer-read-polling-time* SECONDS.
! #-(or symbolics-3600 explorer excl)
(defparameter *buffer-read-polling-time* 0.5)
! #-(or symbolics-3600 explorer excl)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
--- 970,979 ----
(return t))))
;; Poll for input every *buffer-read-polling-time* SECONDS.
! #-(or symbolics-3600 explorer excl lcl3.0)
(defparameter *buffer-read-polling-time* 0.5)
! #-(or symbolics-3600 explorer excl lcl3.0)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
***************
*** 955,960 ****
--- 1021,1042 ----
vector start end))
(error "X write failed: socket dead!")))
+ #+lcl3.0
+ (defun buffer-write-default (vector display start end)
+ ;;We inhibit scheduling here because there seem to be races in Lucid's
+ ;;multitasking implementation. Anyway, when we take it out we get bugs!
+ (declare (type display display)
+ (type buffer-bytes vector)
+ (type array-index start end)
+ (optimize (:tail-merge nil)
+ (speed 3)
+ (safety 0)))
+ (lcl:with-scheduling-inhibited
+ (lcl:write-array
+ (extract-underlying-stream
+ (display-output-stream display) display :output)
+ vector start end)))
+
;;; WARNING:
;;; CLX performance will be severely degraded if your lisp uses
;;; write-byte to send all data to the X Window System server.
***************
*** 961,967 ****
;;; You are STRONGLY encouraged to write a specialized version
;;; of buffer-write-default that does block transfers.
! #-(or symbolics-3600 explorer excl)
(defun buffer-write-default (vector display start end)
;; The default buffer write function for use with common-lisp streams
(declare (type buffer-bytes vector)
--- 1043,1049 ----
;;; You are STRONGLY encouraged to write a specialized version
;;; of buffer-write-default that does block transfers.
! #-(or symbolics-3600 explorer excl lcl3.0)
(defun buffer-write-default (vector display start end)
;; The default buffer write function for use with common-lisp streams
(declare (type buffer-bytes vector)
*** lib/CLX/attributes.l Thu Apr 7 14:27:34 1988
--- lib/LUCID-CLX/attributes.lisp Mon Feb 6 12:24:13 1989
***************
*** 269,288 ****
(deallocate-gcontext-state (state-geometry-changes state-entry))
(setf (state-geometry-changes state-entry) nil))
;; Get drawable attributes
! (with-buffer-request (display *x-getgeometry* :no-after)
! (drawable drawable))
! (let ((buffer (or (state-geometry state-entry)
! (allocate-context))))
! (wait-for-reply display *geometry-size*)
! ;; Copy into event from reply buffer
! (buffer-replace (reply-ibuf8 buffer)
! (reply-ibuf8 (buffer-reply-buffer display))
! 0
! *geometry-size*)
! (when state-entry
! (setf (state-geometry state-entry) buffer))
! (display-invoke-after-function display)
! buffer))))))
(defun put-window-attribute-changes (window changes)
;; change window attributes
--- 269,289 ----
(deallocate-gcontext-state (state-geometry-changes state-entry))
(setf (state-geometry-changes state-entry) nil))
;; Get drawable attributes
! (with-input-lock (display)
! (with-buffer-request (display *x-getgeometry* :no-after)
! (drawable drawable))
! (let ((buffer (or (state-geometry state-entry)
! (allocate-context))))
! (wait-for-reply display *geometry-size*)
! ;; Copy into event from reply buffer
! (buffer-replace (reply-ibuf8 buffer)
! (reply-ibuf8 (buffer-reply-buffer display))
! 0
! *geometry-size*)
! (when state-entry
! (setf (state-geometry state-entry) buffer))
! (display-invoke-after-function display)
! buffer)))))))
(defun put-window-attribute-changes (window changes)
;; change window attributes
*** lib/CLX/macros.l Wed Jun 29 17:46:39 1988
--- lib/LUCID-CLX/macros.lisp Mon Feb 6 12:24:24 1989
***************
*** 725,733 ****
(declare-arglist (buffer &optional size &key sizes) &body body)
(let ((buf (gensym)))
`(let ((,buf ,buffer))
! (wait-for-reply ,buf ,size)
! (reading-buffer-reply (,buf ,@options)
! ,@body))))
(defmacro compare-request ((index) &body body)
`(macrolet ((write-card32 (index item) `(= ,item (read-card32 ,index)))
--- 725,735 ----
(declare-arglist (buffer &optional size &key sizes) &body body)
(let ((buf (gensym)))
`(let ((,buf ,buffer))
! ;;;This better always be called with a display.
! (with-input-lock (,buf)
! (wait-for-reply ,buf ,size)
! (reading-buffer-reply (,buf ,@options)
! ,@body)))))
(defmacro compare-request ((index) &body body)
`(macrolet ((write-card32 (index item) `(= ,item (read-card32 ,index)))
*** lib/CLX/graphics.l Wed Jun 29 17:47:57 1988
--- lib/LUCID-CLX/graphics.lisp Mon Feb 6 12:24:21 1989
***************
*** 422,438 ****
(let ((display (drawable-display drawable))
seq depth visual)
(with-display (display)
! (with-buffer-request (display *x-getimage* :no-after)
! ((data (member error :xy-pixmap :z-pixmap)) format)
! (drawable drawable)
! (int16 x y)
! (card16 width height)
! (card32 plane-mask))
! (with-buffer-reply (display nil :sizes (8 32))
! (setq depth (card8-get 1)
! visual (resource-id-get 8))
! (let ((length (* 4 (card32-get 4))))
! (setq seq (sequence-get :result-type result-type :format card8
! :length length :start start :data data)))))
(display-invoke-after-function display)
(values seq depth visual)))
--- 422,439 ----
(let ((display (drawable-display drawable))
seq depth visual)
(with-display (display)
! (with-input-lock (display)
! (with-buffer-request (display *x-getimage* :no-after)
! ((data (member error :xy-pixmap :z-pixmap)) format)
! (drawable drawable)
! (int16 x y)
! (card16 width height)
! (card32 plane-mask))
! (with-buffer-reply (display nil :sizes (8 32))
! (setq depth (card8-get 1)
! visual (resource-id-get 8))
! (let ((length (* 4 (card32-get 4))))
! (setq seq (sequence-get :result-type result-type :format card8
! :length length :start start :data data))))))
(display-invoke-after-function display)
(values seq depth visual)))
*** lib/CLX/requests.l Mon Jul 18 13:59:12 1988
--- lib/LUCID-CLX/requests.lisp Mon Feb 6 12:24:26 1989
***************
*** 1085,1091 ****
(declare (type colormap colormap)
(type card16 colors planes)
(type boolean contiguous-p)
! (type t result-type)) ;; CL type
(declare-values (sequence pixel) (sequence mask))
(let ((display (colormap-display colormap))
pixel-sequence mask-sequence)
--- 1085,1091 ----
(declare (type colormap colormap)
(type card16 colors planes)
(type boolean contiguous-p)
! (type t result-type));; CL type
(declare-values (sequence pixel) (sequence mask))
(let ((display (colormap-display colormap))
pixel-sequence mask-sequence)
***************
*** 1094,1106 ****
((data boolean) contiguous-p)
(colormap colormap)
(card16 colors planes))
! (with-buffer-reply (display nil :sizes 16)
! (let ((npixels (card16-get 8))
! (nmasks (card16-get 10)))
! (setq pixel-sequence
! (sequence-get :result-type result-type :length npixels))
! (setq mask-sequence
! (sequence-get :result-type result-type :length nmasks)))))
(display-invoke-after-function display)
(values pixel-sequence mask-sequence)))
--- 1094,1107 ----
((data boolean) contiguous-p)
(colormap colormap)
(card16 colors planes))
! (with-input-lock (display)
! (with-buffer-reply (display nil :sizes 16)
! (let ((npixels (card16-get 8))
! (nmasks (card16-get 10)))
! (setq pixel-sequence
! (sequence-get :result-type result-type :length npixels))
! (setq mask-sequence
! (sequence-get :result-type result-type :length nmasks))))))
(display-invoke-after-function display)
(values pixel-sequence mask-sequence)))
***************
*** 1201,1219 ****
(let ((display (colormap-display colormap))
sequence)
(with-display (display)
! (with-buffer-request (display *x-querycolors* :no-after)
! (colormap colormap)
! (sequence pixels))
! (wait-for-reply display nil)
! (reading-buffer-reply (display :sizes (8 16))
! (let* ((ncolors (card16-get 8)))
! (setq sequence (make-sequence result-type ncolors))
! (dotimes (i ncolors sequence)
! (buffer-input display buffer-bbuf 0 8)
! (setf (elt sequence i)
! (make-color :red (rgb-val-get 0)
! :green (rgb-val-get 2)
! :blue (rgb-val-get 4)))))))
(display-invoke-after-function display)
sequence))
--- 1202,1221 ----
(let ((display (colormap-display colormap))
sequence)
(with-display (display)
! (with-input-lock (display)
! (with-buffer-request (display *x-querycolors* :no-after)
! (colormap colormap)
! (sequence pixels))
! (wait-for-reply display nil)
! (reading-buffer-reply (display :sizes (8 16))
! (let* ((ncolors (card16-get 8)))
! (setq sequence (make-sequence result-type ncolors))
! (dotimes (i ncolors sequence)
! (buffer-input display buffer-bbuf 0 8)
! (setf (elt sequence i)
! (make-color :red (rgb-val-get 0)
! :green (rgb-val-get 2)
! :blue (rgb-val-get 4))))))))
(display-invoke-after-function display)
sequence))
∂13-Feb-89 2052 CL-Windows-mailer topics
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 13 Feb 89 20:52:14 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA08574; Mon, 13 Feb 89 23:50:14 -0500
Received: by mcvax.cwi.nl via EUnet; Mon, 13 Feb 89 18:05:21 +0100 (MET)
Received: by inria.inria.fr (5.59++/89.0.5) via Fnet-EUnet id AA09898; Mon, 13 Feb 89 17:32:32 +0100 (MET)
Received: by imag.imag.fr (5.51/5.17)
id AA04555; Mon, 13 Feb 89 16:23:52 +0100
Received: from alma by csinn (1.1/CSI2.0)
id AA00372; Tue, 14 Feb 89 00:21:24 GMT
Return-Path: <fano>
Received: by alma (4.0/CSI2.0)
id AA05300; Mon, 13 Feb 89 16:21:58 +0100
Date: Mon, 13 Feb 89 16:21:58 +0100
From: Fano Ramparany <mcvax!capsogeti.fr!fano@uunet.UU.NET>
Message-Id: <8902131521.AA05300@alma>
To: cl-windows@sail.stanford.edu
Subject: topics
Hello,
I would appreciate your sending me the topics covered by the cl-windows mailing
list
Thanks in advance
Fano Ramparany/////////////////////////////////////////////////////////////////
surf-mail: CAP SESA INNOVATION, chemin du vieux ch\↑{e}ne, 38240 Meylan, FRANCE
audi-mail: +33 76 90 80 40 (telefax +33 76 41 06 29)
elec-mail: { fano@capsogeti.fr | fano@csinn.UUCP }
∂14-Feb-89 1636 CL-Windows-mailer Re: CLX and ICCCM
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Feb 89 16:35:46 PST
Received: by ti.com id AA25430; Tue, 14 Feb 89 18:34:16 CST
Received: from dsg by tilde id AA26613; Tue, 14 Feb 89 18:23:51 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 14 Feb 89 18:22:53 CST
Message-Id: <2812494177-5259471@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 14 Feb 89 18:22:57 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Subject: Re: CLX and ICCCM
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Msg of Thu, 09 Feb 89 16:05:43 -0800 from John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
> I'm not so sure it's a good idea to remove the obsolete x, y, width, and
> height slots [of wm-size-hints]. What if there's a window manager out
> there that uses them? It's a tradeoff between backwards compatibility and
> reduction of confusion. Perhaps having them there but not exporting them
> would be a good compromise.
You're right. These slots should be retained and their accessors should be kept
internal. At first, I thought these fields were being removed from the stored
format of the WM_NORMAL_HINTS property, in which case the incompatibility would
be inevitable. However, I was wrong.
> I don't like the idea of changing the defaults for user-specified to nil.
> Mainly because it's a fairly arbitrary choice -- maybe the user specifically
> asked for it and maybe he didn't -- there isn't a clearcut way to tell like
> there is with normal C programs. Basically I oppose the change because it's
> a backwards incompatibility.
The rationale for user-specified-position/size defaulting to nil is based on an
axiom:
The true arbiter of window geometry is the interactive user.
and two assertions:
1. The default case is the case involving the least effort by the
client.
2. A client that acquires initial window geometry from the interactive
user is doing more work than one that doesn't.
When user-specified-position/size are true, the window manager is expected to
treat them just as if they had been entered interactively by the user. This is
a claim that the client has already done the work to acquire initial window
geometry (e.g. from the command line, from a user interaction, from a resource
file, etc.). Clients which make this claim but do not actually do the work have
always been in error (see axiom). I don't understand the statement that "there
isn't a clearcut way to tell like there is with normal C programs".
I suspect that the effect of this "incompatibility" will mainly be to expose
erroneous clients.
> Are
> you planning to implement the above changes? Is LaMott?
Not immediately. My current commitments won't permit me to work on the
implementation for some time. Probably implementation should await ratification
of ICCCM following the current public review. I'm interested from folks if they
want to help with the implementation and when.
∂15-Feb-89 0443 CL-Windows-mailer Re: CLX and ICCCM
Received: from EXPIRE.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 04:43:03 PST
Received: by expire.lcs.mit.edu; Wed, 15 Feb 89 07:42:11 EST
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Message-Id: <8902151242.AA03314@EXPIRE.LCS.MIT.EDU>
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and ICCCM
In-Reply-To: Your message of Tue, 14 Feb 89 18:22:57 CST.
<2812494177-5259471@Sierra>
Date: Wed, 15 Feb 89 07:42:09 EST
I'm interested from folks if they
want to help with the implementation and when.
I'm presently searching for an MIT student to hire to work on CLX bugs, etc.
If I find someone, s/he may be able to help out.
∂16-Feb-89 1917 CL-Windows-mailer Re: CLX and ICCCM
Received: from EXPIRE.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 04:43:03 PST
Received: by expire.lcs.mit.edu; Wed, 15 Feb 89 07:42:11 EST
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Message-Id: <8902151242.AA03314@EXPIRE.LCS.MIT.EDU>
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and ICCCM
In-Reply-To: Your message of Tue, 14 Feb 89 18:22:57 CST.
<2812494177-5259471@Sierra>
Date: Wed, 15 Feb 89 07:42:09 EST
I'm interested from folks if they
want to help with the implementation and when.
I'm presently searching for an MIT student to hire to work on CLX bugs, etc.
If I find someone, s/he may be able to help out.
∂17-Feb-89 0716 CL-Windows-mailer CL-PEX?
Received: from helios.northeastern.edu by SAIL.Stanford.EDU with TCP; 17 Feb 89 07:16:16 PST
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa23512; 17 Feb 89 10:13 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.5)
id AA07879; Fri, 17 Feb 89 10:11:26 EST
Date: Fri, 17 Feb 89 10:11:26 EST
From: George McKee <mckee@corwin.ccs.northeastern.edu>
Message-Id: <8902171511.AA07879@corwin.CCS.Northeastern.EDU>
To: cl-windows@sail.stanford.edu
Subject: CL-PEX?
Is is too early to start thinking about lisp bindings for 3-d
graphics using X? We've just finished putting X11R3 up on our networks,
so I haven't started seriously working with CLX or CLUE yet, and thus
can't contribute to any work in this area. However, I can forsee
a clear need for it in my research, so I'd like to know that a standard
will be available when I need it...
Is work on 3-dimensional-graphics-in-Lisp-via-X ongoing that I'm
unaware of, and maybe a list that I should be subscribing to?
- George McKee
Software Coordinator
College of Computer Science
Northeastern University, Boston 02115
CSnet: mckee@Corwin.CCS.Northeastern.EDU
Internet: mckee%Corwin.CCS.Northeastern.EDU@Relay.CS.NET
Phone: (617) 437-5204
uucp: ...iuvax!corwin!mckee (don't ask why)
Disclaimer: I'm not an authority on anything, particularly this stuff.
∂17-Feb-89 0743 CL-Windows-mailer Re: CL-PEX?
Received: from EXPIRE.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 07:42:51 PST
Received: by expire.lcs.mit.edu; Fri, 17 Feb 89 10:39:10 EST
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Message-Id: <8902171539.AA03847@EXPIRE.LCS.MIT.EDU>
To: George McKee <mckee@corwin.ccs.northeastern.edu>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CL-PEX?
In-Reply-To: Your message of Fri, 17 Feb 89 10:11:26 EST.
<8902171511.AA07879@corwin.CCS.Northeastern.EDU>
Date: Fri, 17 Feb 89 10:39:08 EST
The official programming interface for the PEX extension will be the
official programming interface for PHIGS, plus the de facto or
offical programming interface for PHIGS+. I don't know if ANSI or
ISO is working on a CL binding for PHIGS, but ANSC X3H3.4 (Bindings)
might be a good place to start. I can give you the phone number
of the chair of that committee if you're interested in pursuing it.
∂17-Feb-89 0849 CL-Windows-mailer Re: CL-PEX?
Received: from ti.com by SAIL.Stanford.EDU with TCP; 17 Feb 89 08:49:50 PST
Received: by ti.com id AA07910; Fri, 17 Feb 89 10:48:22 CST
Received: from dsg by tilde id AA07491; Fri, 17 Feb 89 10:35:13 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 17 Feb 89 10:33:57 CST
Message-Id: <2812725278-2629243@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 17 Feb 89 10:34:38 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: CL-PEX?
In-Reply-To: Msg of Fri, 17 Feb 89 10:39:08 EST from rws@expo.lcs.mit.edu (Bob Scheifler)
> I don't know if ANSI or
> ISO is working on a CL binding for PHIGS, but ANSC X3H3.4 (Bindings)
> might be a good place to start.
My understanding from Madeleine Sparks is that no, there is no ANSI/ISO work
item for a CL PHIGS binding. Interest in CL bindings has only recently begun to
surface. A CL GKS binding is in progress, but in general X3H3.4 does not have a
great deal of expertise or manpower for CL bindings.
∂17-Feb-89 1414 CL-Windows-mailer Recent Lucid patches for CLX
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Feb 89 14:14:47 PST
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA04611g; Fri, 17 Feb 89 13:13:59 PST
Site:
Received: by rainbow-warrior id AA05745g; Fri, 17 Feb 89 13:16:52 PST
Date: Fri, 17 Feb 89 13:16:52 PST
From: Judy Anderson <yduJ@lucid.com>
Message-Id: <8902172116.AA05745@rainbow-warrior>
To: cl-windows@sail.stanford.edu, bug-clx@expo.lcs.mit.edu,
xpert@athena.mit.edu
Subject: Recent Lucid patches for CLX
Well, I can't program my way out of a paper bag, it seems clear.
Thanks to Hans Muller of Sun for a pair of scissors to cut my way out...
I confused "alists" with "plists" in my recent set of patches, and
since Hans hadn't been confused, I broke his code. Here's a patch to
my patch, using the plist correctly this time. Oh the embarrassment.
yduJ (Judy Anderson)
Lucid, Inc.
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
---------------------------------------------------------------------------
*** lib/CLX/dependent.l Thu Feb 9 11:12:48 1989
--- lib/LUCID-CLX/dependent.lisp Fri Feb 17 13:09:38 1989
***************
*** 904,916 ****
(defmacro extract-underlying-stream (stream display direction)
;;;Our job is to quickly get at the underlying stream for this display's
;;;input stream structure.
! `(let ((pair (assoc ,direction (display-plist ,display))))
! (if pair (second pair)
! (progn
! (push (list ,direction
! (lucid::underlying-stream ,stream ,direction))
! (display-plist ,display))
! (second (assoc ,direction (display-plist ,display)))))))
#+lcl3.0
(defun buffer-read-default (display vector start end timeout)
--- 904,914 ----
(defmacro extract-underlying-stream (stream display direction)
;;;Our job is to quickly get at the underlying stream for this display's
;;;input stream structure.
! `(or (getf (display-plist ,display) ,direction)
! (setf (getf (display-plist ,display) ,direction)
! (lucid::underlying-stream ,stream (if (eq ,direction 'input)
! :input
! :output)))))
#+lcl3.0
(defun buffer-read-default (display vector start end timeout)
***************
*** 925,931 ****
(optimize (speed 3)
(safety 0)))
(let* ((stream (display-input-stream display))
! (fast-stream (extract-underlying-stream stream display :input)))
(cond ((or (null timeout)
(listen stream))
(lcl:with-scheduling-inhibited
--- 923,929 ----
(optimize (speed 3)
(safety 0)))
(let* ((stream (display-input-stream display))
! (fast-stream (extract-underlying-stream stream display 'input)))
(cond ((or (null timeout)
(listen stream))
(lcl:with-scheduling-inhibited
***************
*** 1034,1040 ****
(lcl:with-scheduling-inhibited
(lcl:write-array
(extract-underlying-stream
! (display-output-stream display) display :output)
vector start end)))
;;; WARNING:
--- 1032,1038 ----
(lcl:with-scheduling-inhibited
(lcl:write-array
(extract-underlying-stream
! (display-output-stream display) display 'output)
vector start end)))
;;; WARNING:
∂20-Feb-89 0618 CL-Windows-mailer Re: CL-PEX?
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Feb 89 06:17:49 PST
Received: from ai.leeds.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00175; 20 Feb 89 12:53 GMT
Via: kebc.icl.stc.co.uk (ss0.ARPA); Mon, 20 Feb 89 12:03:18 GMT
Received: from ss1.kebc.icl.stc.co.uk by kebc.icl.stc.co.uk; Mon, 20 Feb 89 12:03:05 GMT
To: mckee@corwin.ccs.northeastern.edu,
George%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
McKee%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
aer%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
jdm%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
rodw%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK
MMDF-Warning: Parse error in original version of preceding line at .NSS.Cs.Ucl.AC.UK
Subject: Re: CL-PEX?
Cc: cl-windows@sail.stanford.edu, jwd%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK
From: Bob Scheifler <rws@expo.lcs.mit.edu>
Message-Id: <8902171539.AA03847@EXPIRE.LCS.MIT.EDU>
In-Reply-To: Your message of Fri, 17 Feb 89 10:11:26 EST.
<8902171511.AA07879@corwin.CCS.Northeastern.EDU>
Date: Fri, 17 Feb 89 10:39:08 EST
Sender: cl-windows-request@NSS.Cs.Ucl.AC.UK
Status: R
The official programming interface for the PEX extension will be the
official programming interface for PHIGS, plus the de facto or
offical programming interface for PHIGS+. I don't know if ANSI or
ISO is working on a CL binding for PHIGS, but ANSC X3H3.4 (Bindings)
might be a good place to start. I can give you the phone number
of the chair of that committee if you're interested in pursuing it.
∂20-Feb-89 0634 CL-Windows-mailer Re: CL-PEX?
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Feb 89 06:33:54 PST
Received: from ai.leeds.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00552; 20 Feb 89 13:15 GMT
Via: kebc.icl.stc.co.uk (ss0.ARPA); Mon, 20 Feb 89 13:16:52 GMT
Received: from ss1.kebc.icl.stc.co.uk by kebc.icl.stc.co.uk; Mon, 20 Feb 89 13:16:34 GMT
From: "Mark W. Reeder" <REEDER%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 20 Feb 89 13:11:37 GMT
Message-Id: <2594.8902201311@ss1.kebc.icl.stc.co.uk>
To: aer%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK, cl-windows@sail.stanford.edu,
jdm%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
rodw%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK
Subject: Re: CL-PEX?
In-Reply-To: Msg of Fri, 17 Feb 89 10:39:08 EST from rws@expo.lcs.mit.edu (Bob Scheifler)
Sender: cl-windows-request@NSS.Cs.Ucl.AC.UK
Status: R
> I don't know if ANSI or
> ISO is working on a CL binding for PHIGS, but ANSC X3H3.4 (Bindings)
> might be a good place to start.
My understanding from Madeleine Sparks is that no, there is no ANSI/ISO work
item for a CL PHIGS binding. Interest in CL bindings has only recently begun to
surface. A CL GKS binding is in progress, but in general X3H3.4 does not have a
great deal of expertise or manpower for CL bindings.
∂20-Feb-89 0642 CL-Windows-mailer Recent Lucid patches for CLX
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Feb 89 06:38:26 PST
Received: from ai.leeds.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00594; 20 Feb 89 13:18 GMT
Via: kebc.icl.stc.co.uk (ss0.ARPA); Mon, 20 Feb 89 13:19:10 GMT
Received: from ss1.kebc.icl.stc.co.uk by kebc.icl.stc.co.uk; Mon, 20 Feb 89 13:18:50 GMT
To: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu,
jwd%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK,
rodw%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK, xpert@athena.mit.edu
Subject: Recent Lucid patches for CLX
Received: by rainbow-warrior id AA05745g; Fri, 17 Feb 89 13:16:52 PST
Date: Fri, 17 Feb 89 13:16:52 PST
From: Judy Anderson <yduJ%lucid.com@NSS.Cs.Ucl.AC.UK>
Message-Id: <8902172116.AA05745@rainbow-warrior>
Sender: cl-windows-request@NSS.Cs.Ucl.AC.UK
Status: R
Well, I can't program my way out of a paper bag, it seems clear.
Thanks to Hans Muller of Sun for a pair of scissors to cut my way out...
I confused "alists" with "plists" in my recent set of patches, and
since Hans hadn't been confused, I broke his code. Here's a patch to
my patch, using the plist correctly this time. Oh the embarrassment.
yduJ (Judy Anderson)
Lucid, Inc.
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
---------------------------------------------------------------------------
*** lib/CLX/dependent.l Thu Feb 9 11:12:48 1989
--- lib/LUCID-CLX/dependent.lisp Fri Feb 17 13:09:38 1989
***************
*** 904,916 ****
(defmacro extract-underlying-stream (stream display direction)
;;;Our job is to quickly get at the underlying stream for this display's
;;;input stream structure.
! `(let ((pair (assoc ,direction (display-plist ,display))))
! (if pair (second pair)
! (progn
! (push (list ,direction
! (lucid::underlying-stream ,stream ,direction))
! (display-plist ,display))
! (second (assoc ,direction (display-plist ,display)))))))
#+lcl3.0
(defun buffer-read-default (display vector start end timeout)
--- 904,914 ----
(defmacro extract-underlying-stream (stream display direction)
;;;Our job is to quickly get at the underlying stream for this display's
;;;input stream structure.
! `(or (getf (display-plist ,display) ,direction)
! (setf (getf (display-plist ,display) ,direction)
! (lucid::underlying-stream ,stream (if (eq ,direction 'input)
! :input
! :output)))))
#+lcl3.0
(defun buffer-read-default (display vector start end timeout)
***************
*** 925,931 ****
(optimize (speed 3)
(safety 0)))
(let* ((stream (display-input-stream display))
! (fast-stream (extract-underlying-stream stream display :input)))
(cond ((or (null timeout)
(listen stream))
(lcl:with-scheduling-inhibited
--- 923,929 ----
(optimize (speed 3)
(safety 0)))
(let* ((stream (display-input-stream display))
! (fast-stream (extract-underlying-stream stream display 'input)))
(cond ((or (null timeout)
(listen stream))
(lcl:with-scheduling-inhibited
***************
*** 1034,1040 ****
(lcl:with-scheduling-inhibited
(lcl:write-array
(extract-underlying-stream
! (display-output-stream display) display :output)
vector start end)))
;;; WARNING:
--- 1032,1038 ----
(lcl:with-scheduling-inhibited
(lcl:write-array
(extract-underlying-stream
! (display-output-stream display) display 'output)
vector start end)))
;;; WARNING:
!!!! so there [MWR]
∂22-Feb-89 1010 CL-Windows-mailer Profuse apologies
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Feb 89 10:10:06 PST
Received: from ai.leeds.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01111; 22 Feb 89 17:17 GMT
Via: kebc.icl.stc.co.uk (ss0.ARPA); Wed, 22 Feb 89 17:20:22 GMT
From: "Mark W. Reeder" <REEDER%kebc.icl.stc.co.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 22 Feb 89 17:20:07 GMT
Message-Id: <15547.8902221720@kebc.icl.stc.co.uk>
To: cl-windows@sail.stanford.edu
Subject: Profuse apologies
...for reflected messages Mon 20 Feb.
I assume due to my clumsy use of Suntools mail tool.
Mark
∂28-Feb-89 1504 CL-Windows-mailer Newer version of preliminary clx document available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Feb 89 15:04:34 PST
Received: by ti.com id AA29090; Tue, 28 Feb 89 17:04:04 CST
Received: from home by tilde id AA16696; Tue, 28 Feb 89 16:57:06 CST
Received: by home id AA08114; Tue, 28 Feb 89 16:56:53 CST
Date: Tue, 28 Feb 89 16:56:53 CST
From: Mikie <myjak@home.csc.ti.com>
Message-Id: <8902282256.AA08114@home>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Cc: myjak@ti-csl.csc.ti.com
Subject: Newer version of preliminary clx document available
Date: Fri, 24 Feb 89 19:34:58 CST
From: Mikie <myjak@home.csc.ti.com> (Michael D. Myjak)
A newer version of the preliminary CLX document can be found on
csc.ti.com:~ftp/pub/clx.doc (and clx.doc.Z for the compressed
version).
Please feel free to use anonymous ftp to grab a copy of this
*preliminary* document. Look for a complete version to be available
around the end of next month. Tech-pubs will be generating the
official copy, but, alas, the format will not be compatible for
FTP. I will post again when and where hard copies will be available.
Michael D. Myjak
Computer Virus: n., pl. -ruses. 1) Any of various post-compilation pathogens
consisting essentially of a core of hexadecimal characters surrounded by a
benign software coat, having the ability to fit through a pinhole in the
condom of security and replicate within a computing environment.
∂01-Mar-89 1134 CL-Windows-mailer Please change address to "tbardasz@cvbnet.prime.com"
Received: from EN-C06.Prime.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:34:22 PST
Received: from cvbnet.prime.com by EN-C06.Prime.COM; 01 Mar 89 14:13:17 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA01985; Wed, 1 Mar 89 14:17:22 EST
Date: Wed, 1 Mar 89 14:17:22 EST
From: root@cvbnet.prime.com (Operator)
Message-Id: <8903011917.AA01985@cvbnet.prime.com>
To: cl-windows@sail.stanford.edu
Subject: Please change address to "tbardasz@cvbnet.prime.com"
From MAILER-DAEMON Wed Mar 1 10:05:23 1989
Return-Path: <MAILER-DAEMON>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AB00695; Wed, 1 Mar 89 10:05:10 EST
Date: Wed, 1 Mar 89 10:05:10 EST
From: MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8903011505.AB00695@cvbnet.prime.com>
To: Postmaster
Status: R
----- Transcript of session follows -----
554 basie!tbardasz... No known UUCP connection to basie
554 decvax!SAIL.Stanford.EDU!CL-Windows-mailer... Possible alias loop
554 No valid recipients
----- Message header follows -----
Return-Path: <SAIL.Stanford.EDU!CL-Windows-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA00695; Wed, 1 Mar 89 10:05:10 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
id AA19887; Tue, 28 Feb 89 15:24:57 PST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA19887; Tue, 28 Feb 89 15:24:57 PST
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Feb 89 15:04:34 PST
Received: by ti.com id AA29090; Tue, 28 Feb 89 17:04:04 CST
Received: from home by tilde id AA16696; Tue, 28 Feb 89 16:57:06 CST
Received: by home id AA08114; Tue, 28 Feb 89 16:56:53 CST
Date: Tue, 28 Feb 89 16:56:53 CST
From: Mikie <home.csc.ti.com!myjak@decvax.uucp>
Message-Id: <8902282256.AA08114@home>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Cc: myjak@ti-csl.csc.ti.com
Subject: Newer version of preliminary clx document available
∂08-Mar-89 1508 CL-Windows-mailer CLX and ICCCM
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 8 Mar 89 15:08:11 PST
Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Wed 8 Mar 89 17:04:18-CST
Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56)
id AA07344; Wed, 8 Mar 89 17:04:15 CST
Date: Wed, 8 Mar 89 17:04:13 CST
From: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Message-Id: <8903082304.AA13984@perseus.sw.mcc.com>
Received: by perseus.sw.mcc.com (3.2/STP1.14)
id AA13984; Wed, 8 Mar 89 17:04:13 CST
To: Kimbrough@dsg.csc.ti.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Kerry Kimbrough's message of Tue, 7 Feb 89 20:03:31 CST <2811895411-1805738@Sierra>
Subject: CLX and ICCCM
Kerry, A while back I got a note from someone at TI (perhaps you)
asking about DELPHI common lisp. At the time I asked around and came
up blank. The funny thing was that he had gotten a note from someone
he forgot at MCC ... In case you are or know who wanted the info ...
Date: Wed, 1 Mar 89 03:14 CST
From: David Schatsky <delphi!david@Sun.COM>
I work for an Italian company called Delphi. Delphi was founded in
'82 and has about 60 people working in A.I., open systems, and
distribution of various products including worstations and
supercomputers. Delphi hired me to help them become an international
company, and I'm responsible for international sales of Delphi's A.I.
products. The main product is Delphi Common Lisp, a brief description
of which I've appended to the end of this message.
Bill told me that some people might be interested in
Delphi Common Lisp for your work. What do you think?
Regards,
David SCHATSKY (david@delphi.uucp)
Delphi S.p.A.
Via della Vetraia, 11
I-55049 Viareggio, Italy
Tel: +39 (584) 395225
Fax: +39 (584) 395366
tlx: 501542 DELPHI I
-------------------------------------------------------------------------------
Delphi Common Lisp (DCL) is a complete implementation of Common Lisp
derived from the popular implementation from Kyoto University. It has
all of the advantages of Kyoto implementation such as:
- Complete implementation
- Robust
- small size--can run with 4MB
- good C interface--Lisp and C can be intermixed
in same file and Lisp can invoke C functions
Plus, Delphi Common Lisp has several major extensions which make it a
much more complete Common Lisp programming environment:
- Performance enhancements. DCL performs at +/- 10% of Lucid
on the Gabriel benchmarks.
- An integrated implementation of the Common Lisp Object
System (CLOS). Delphi implemented CLOS from scratch
and optimized for the data structures used in the DCL
kernel. The meta-object protocol is not yet supported.
- Multithread support for concurrency. The Multithread
primitives can also be used to implement semaphores, OCCAM
channels and other typical concurrency schemes. A small
amount of code can be written to emulate efficiently
the concurrency metaphors of other Lisps. Delphi has
already implemented extensions to CLOS to allow the definition
of concurrent synchronizable atomic methods.
- High-performance CLX interface to the X Window System.
Delphi's CLX performs as much as 40 times faster than the
public domain versions floating around.
Pricing of DCL is good, at around $2000 for the Sun 3. It currently
runs on all the Suns (2, 3, 4, 386i) and Apollo DN. A version for
386/Unix is in beta test. Ports are in the works for other workstations
(HP, IBM, Sony), as well as new architecture machines like NCube,
Multiflow, and Cray.
;rob
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp
∂08-Mar-89 1511 CL-Windows-mailer apologies for the inadvertent cc to cl-windows
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 8 Mar 89 15:11:00 PST
Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Wed 8 Mar 89 17:08:34-CST
Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56)
id AA07361; Wed, 8 Mar 89 17:08:28 CST
Date: Wed, 8 Mar 89 17:08:26 CST
From: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Message-Id: <8903082308.AA14032@perseus.sw.mcc.com>
Received: by perseus.sw.mcc.com (3.2/STP1.14)
id AA14032; Wed, 8 Mar 89 17:08:26 CST
To: cl-windows@sail.stanford.edu
Subject: apologies for the inadvertent cc to cl-windows
... a result of the hazards of yanking mail headers in a hurry.
;rob
∂09-Mar-89 1636 CL-Windows-mailer CLX doc update
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 16:36:14 PST
Received: by ti.com id AA00151; Thu, 9 Mar 89 11:05:45 CST
Received: from home by tilde id AA20275; Thu, 9 Mar 89 10:06:34 CST
Received: by home id AA05680; Thu, 9 Mar 89 10:06:23 CST
Date: Thu, 9 Mar 89 10:06:23 CST
From: Mikie <myjak@home.csc.ti.com>
Message-Id: <8903091606.AA05680@home>
To: franz!sparky!jdi@ucbarpa.Berkeley.EDU, andreasg@boulder.Colorado.EDU,
yduj@lucid.com, clue-review@dsg.csc.ti.com,
cl-windows@sail.stanford.edu
Cc: myjak@ti-csl.csc.ti.com, stenger@dls.csc.ti.com, oren@stroke.csc.ti.com,
ekberg@m5.csc.ti.com
Subject: CLX doc update
Date: Wed, 08 Mar 89 18:30:57 -0800
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
How about a postscript version of the output in the ftp directory?
-- John
Date: Wed, 8 Mar 89 10:01:59 MST
From: Andreas Girgensohn <andreasg@boulder.Colorado.EDU>
I'm just starting using X Windows and CLX on a Symbolics Lispmachine.
Unfortunately, the documentation for CLX is in a format that makes it
difficult to read. Do you have a version of the documentation for
LaTeX/Scribe/Troff or a Postscript output? Does the file pub/clx.doc.Z
from Feb. 27 contain the newest version?
--Andreas Girgensohn <andreasg@boulder.colorado.edu>
A newer version (3/8/89) of the preliminary CLX document can be found
on csc.ti.com:~ftp/pub/clx.doc (and clx.doc.Z for the compressed
version).
There is now a (albeit slightly older 3/4/89) version molded into
LaTeX that is now available. Please note that it comes with a seperate
index file. The files are as follows:
clx.doc current, updated ASCII version
clx.doc.tex last weeks version, in LaTeX,
clx.doc.ind index file, which is to be \input into above LaTeX file
The files are located in csc.ti.com in the ~ftp/pub directory.
Compressed versions (.Z) are also available.
As for the postscript version, we're working an dvi2ps program. All I
know at this time is that we have three different version, of which
neither works without problems. As soon as these problems are
resolved, we'll try to get a postscript version (built from the LaTeX
version) out on csc.ti.com.
Please direct any comments/suggestions/corrections to me @
myjak@csc.ti.com and I'll get back to you as soon as possible.
and thanks for your support.
--Michael D. Myjak
Computer Virus: n., pl. -ruses. 1) Any of various post-compilation pathogens
consisting essentially of a core of hexadecimal characters surrounded by a
benign software coat, having the ability to fit through a pinhole in the
condom of security and replicate within a computing environment.
∂09-Mar-89 1832 CL-Windows-mailer Re: CLX and ICCCM
Received: from SPARK.BRL.MIL by SAIL.Stanford.EDU with TCP; 9 Mar 89 18:32:03 PST
Date: Thu, 9 Mar 89 21:27:01 EST
From: Phil Dykstra <phil@BRL.MIL>
To: Rob Pettengill <rcp%sw.MCC.COM@mcc.com>
cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and ICCCM
Message-ID: <8903092127.aa24734@SPARK.BRL.MIL>
Rob,
I was glad your note did go to cl-windows, I found the DELPHI common lisp
remarks interesting. You mentioned that it had:
- Multithread support for concurrency. The Multithread
primitives can also be used to implement semaphores, OCCAM
channels and other typical concurrency schemes. A small
amount of code can be written to emulate efficiently
the concurrency metaphors of other Lisps. Delphi has
already implemented extensions to CLOS to allow the definition
of concurrent synchronizable atomic methods.
Is there some emerging standard or proposed standards for concurrency
control in Common Lisp? I was toying with adding such to AKCL but I
would rather not make up my own interface if there's an accepted one
out there.
- Phil
∂10-Mar-89 0832 CL-Windows-mailer Multithreaded Common Lisps
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 08:32:19 PST
Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Fri 10 Mar 89 10:28:16-CST
Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56)
id AA28886; Fri, 10 Mar 89 10:28:03 CST
Date: Fri, 10 Mar 89 10:28:01 CST
From: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
Message-Id: <8903101628.AA01495@perseus.sw.mcc.com>
Received: by perseus.sw.mcc.com (3.2/STP1.14)
id AA01495; Fri, 10 Mar 89 10:28:01 CST
To: phil@BRL.MIL
Cc: rcp%sw.MCC.COM@mcc.com, cl-windows@sail.stanford.edu
In-Reply-To: Phil Dykstra's message of Thu, 9 Mar 89 21:27:01 EST <8903092127.aa24734@SPARK.BRL.MIL>
Subject: Multithreaded Common Lisps
Date: Thu, 9 Mar 89 21:27:01 EST
From: Phil Dykstra <phil@BRL.MIL>
Rob,
I was glad your note did go to cl-windows, I found the DELPHI common lisp
remarks interesting. You mentioned that it had:
- Multithread support for concurrency. The Multithread
primitives can also be used to implement semaphores, OCCAM
channels and other typical concurrency schemes. A small
amount of code can be written to emulate efficiently
the concurrency metaphors of other Lisps. Delphi has
already implemented extensions to CLOS to allow the definition
of concurrent synchronizable atomic methods.
Is there some emerging standard or proposed standards for concurrency
control in Common Lisp? I was toying with adding such to AKCL but I
would rather not make up my own interface if there's an accepted one
out there.
- Phil
This may be a little off topic for cl-windows, but multi-thread
support is very handy for event driven window interfaces. The MCC
DELI Window System interface (no relation to DELPHI) relies heavily on
multi-threading above the retagetable Window System Independent
Interface layer.
Most of the compiler vendors seem to be using the same stack group
based model found in the MIT Lisp Machine and descendants. Lucid
doesn't export their stack groups, but the multi-thread interface is a
bare bones version of the MIT support, Franz Allegro has very closely copied
the Lisp Machine interface. I understand that Gold Hill has stack
group support - so the multi-thread interface should be easy to write.
KCL has been a noteable exception, which is one reason why DELPHI was
of interest. The Xerox Interlisp based machines used a different
model - the spaghetti stack. At MCC we wrote a multi-thread interface
module which paper over the syntactic differences between the
Symbolics, Lucid, and Franz Allegro compiler multi-thread interfaces.
Unfortunatly we chose a slightly different syntax from the MIT Lisp
Machine. I don't have a details on what DELPHI has done, but I would
recommend the MIT semantics and syntax because:
1. A large body of existing code uses it (ie any multi-process code
written for MIT flavor lisp machines).
2. Already supported by multiple vendors (Franz, LMI/Gigamos,
Symbolics, and TI with Lucid using the same semantic model).
;rob
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp
∂13-Mar-89 0423 CL-Windows-mailer need to get CLX & CLUE working on a sun4 running lucid lisp
Received: from santra.hut.fi ([128.214.3.1]) by SAIL.Stanford.EDU with TCP; 13 Mar 89 04:22:53 PST
Received: from hupu.hut.fi by santra.hut.fi
(5.59++/7.0/TeKoLa) id AA10455; Mon, 13 Mar 89 14:19:54 +0200
Received: by hupu.HUT.FI (5.61/5.17)
id AA01237; Mon, 13 Mar 89 14:17:50 +0200
From: ylo@hupu.HUT.FI (Tatu Juhani Yl|nen)
Message-Id: <8903131217.AA01237@hupu.HUT.FI>
Subject: need to get CLX & CLUE working on a sun4 running lucid lisp
To: cl-windows@sail.stanford.edu
Date: Mon, 13 Mar 89 14:17:46 EET
Cc: ylo@hupu.HUT.FI
X-Mailer: Elm [version 2.1 PL1]
We need to get CLX & CLUE working on a sun4 running Sun (Lucid) Common
Lisp.
1) We need to get the current version. We have the version on X11R3
distribution tapes (1.12 or something). Where can we get updates
or the new version? I have access to the internet.
2) Has anyone got CLUE working on Sun (Lucid) lisp? We have version
2.2.1. CLX seems to work ok, but CLUE has several problems, most
of which I would attribute to the compiler/interpreter.
- examples/valuators.lisp does not compile. No apparent reason.
- compiler-let does not work as expected (defmethod expands to
something like
(compiler-let (...)
...
(defun ...
(with-slots ...)))
with-slots expects to find the type of the argument in a variable
set by compiler-let, but at least in interpreted code the variable
is no longer bound when the macros inside the defun are expanded.
However, this construct seems to work sometimes, perhaps in compiled
code. Only we cannot compile all files.
- resource.lisp works differently when compiled or interpreted.
In particular, the convert generic function does not work properly
when calling itself recursively in compiled code; however,
interpreted code works ok.
Are these problems with CLUE, or are these compiler problems? Would
updating to lisp version 3.0 help? I understand lucid has been using
at least CLX with their lisp.
To summarize:
- where can I get the current versions of CLX and CLUE?
- do they work with Sun (Lucid) Common lisp version 2.2.1?
- do they work with version 3.0?
Thanks in advance.
Tatu Yloenen Helsinki University of Technology, Helsinki, Finland.
ylo@hupu.hut.fi
..!uunet!mcvax!santra!hupu!ylo
∂14-Mar-89 1731 CL-Windows-mailer Re: CL-PEX?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:15:00 PST
Date: 14 Mar 89 16:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: CL-PEX?
In-reply-to: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>'s message of Fri,
17 Feb 89 10:34:38 CST
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@sail.stanford.edu
Message-ID: <890314-161500-2223@Xerox>
The fellow doing the GKS binding for X3H3.4 is:
Ross Miller
University of Lowell
CPE
1 University Ave
Lowell, Mass 01854
I had a phone number but I seem to have misplaced it.
He mentioned that they thought they might do a PHIGS binding next. They
didn't have a draft. If you had any input or suggestions, you should
contact him directly.
∂15-Mar-89 1639 CL-Windows-mailer Re: Multiple-font strings and char encodings in CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 16:36:42 PST
Received: by ti.com id AA14625; Wed, 15 Mar 89 15:45:40 CST
Received: from dsg by tilde id AA29915; Wed, 15 Mar 89 11:28:44 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 15 Mar 89 11:27:30 CST
Message-Id: <2814974789-12711902@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 15 Mar 89 11:26:29 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: Multiple-font strings and char encodings in CLX
In-Reply-To: Msg of Mon, 13 Mar 89 14:26:54 +0100 from mcvax!gmdzi!gs3!yvw@uunet.uu.net (Yvo Van Wezemael)
> What is the relation between the 16-bit strings and multiple-font-strings?
You need to manage and implement any such relationship yourself. The idea is
that you need to provide a :translate function which is smart enough to
input your (implementation-dependent) encoding of multiple-font-string
(perhaps a sequence of characters with font bits, where the font bits are an
implementation-dependent font identifier) and then output a sequence of
8- or 16-bit glyph indexes or a xlib:font change. The draw-glyphs function can
then automatically construct the appropriate PolyText8/16 request.
Your :translate function is thus responsible for converting
implementation-dependent font identifiers (e.g. font bits) into xlib:font
objects. The :translate function interface allows it to return a font change,
but *not* a change in glyph index size. (See the source for
xlib:translate-default). That is, draw-glyphs assumes that, regardless of any
font change, the objects in the sequence of "characters" will always be
translated into glyph indexes of the same size (given by the :size argument).
This reminds me of some related questions that have been bothering me lately.
I'd like to design an international text displayer which could handle text in
multiple character set encodings. Many of the pieces to do this are in place in
X11 R3. For example, given a character set identifier and a font name string, I
can open an xlib:font which accepts glyph indexes in the given encoding. Given a
sequence of such glyph indexes, I can then display them.
Question 1: What char encodings are used by various Lisps? char-code is
not guaranteed to return an ASCII code (although it does in my Lisp).
How can my text displayer ask a Lisp string what encoding it's using?
Question 2: Given a char set identifier, how do I know if I need to draw
with 8- or 16-bit size indexes?
∂16-Mar-89 0605 CL-Windows-mailer Re: Multiple-font strings and char encodings in CLX
Received: from EXPIRE.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:05:11 PST
Received: by expire.lcs.mit.edu; Thu, 16 Mar 89 09:03:02 EST
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Message-Id: <8903161403.AA10467@EXPIRE.LCS.MIT.EDU>
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: Multiple-font strings and char encodings in CLX
In-Reply-To: Your message of Wed, 15 Mar 89 11:26:29 CST.
<2814974789-12711902@Sierra>
Date: Thu, 16 Mar 89 09:02:57 EST
Question 2: Given a char set identifier, how do I know if I need to draw
with 8- or 16-bit size indexes?
You either "know", based on intrinsic knowledge of the char set, or else
you look at the font instance and see how many glyphs it has, or else you
simply use 16 bits as a worst case (no harm will come).
∂17-Mar-89 1159 CL-Windows-mailer CLX vs. Ultrix
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:59:08 PST
Received: from jack-jr ([192.9.200.25]) by heavens-gate.lucid.com id AA01885g; Thu, 16 Mar 89 13:39:19 PST
Received: by jack-jr id AA13098g; Thu, 16 Mar 89 13:41:41 PST
Date: Thu, 16 Mar 89 13:41:41 PST
From: Don Tillman <till@lucid.com>
Message-Id: <8903162141.AA13098@jack-jr>
To: cl-windows@sail.stanford.edu
Subject: CLX vs. Ultrix
Apologies if this was already discussed, but could somebody clue me in
on the incompatibilities that the Ultrix X-server has with CLX?
Any call to QUERY-FONT (or anything that uses QUERY-FONT) blows out
during WAIT-FOR-REPLY with an:
">>Error: X-Error: Reply out of sequence
for display #<DISPLAY hostname 0>. "
This happens when the server is the microVax ([Ultrix-32 V3.0 (Rev 64)
UWS V2.0). This happens when the client is either R2 or R3 CLX
running on either said microVax or a Sun.
Anybody seen this before?
- Don Tillman
till@lucid.com
∂19-Mar-89 1301 CL-Windows-mailer Re: Multiple-font strings and char encodings in CLX
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Mar 89 13:01:17 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560676; Sun 19-Mar-89 15:58:07 EST
Date: Sun, 19 Mar 89 15:57 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Multiple-font strings and char encodings in CLX
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2814974789-12711902@Sierra>
Message-ID: <19890319205758.1.MMCM@OWL.SCRC.Symbolics.COM>
You should not really care about the bit encoding used for the element
of a string. It is the identity of the characters, not their encoding,
which matters.
Think of character encodings as ordered sets of characters, not as a
partitioning of the character space. The encodings are a mapping from
index to character.
You do not want to assume that all fonts have the same encoding. Unless
someone goes to a lot of trouble to design a whole new bunch of them,
they will not. You wouldn't want to use the standard distributed BDF
fonts on a Mac, for instance, because of the quite different resolution.
Conceptually, to display a character, you look at all the character sets
(encodings) of which it is a member. For each, you look for a font that
satisfies the character's other attributes (such as size or bold and/or
oblique). If you find one, then you index with the character's index in
that encoding (conceptually based on searching for the character as an
object in the character encoding definition).
Of course, for efficiency, you want to recognize the common case of the
bit encoding of the character having something to do with the index into
the font. But don't build it in all the way through.
∂20-Mar-89 0704 CL-Windows-mailer CLUE on KCL
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Mar 89 07:04:02 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa11185; 20 Mar 89 8:36 EST
Received: from utokyo-relay by RELAY.CS.NET id aa00733; 20 Mar 89 8:31 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA12115; Mon, 20 Mar 89 19:33:23 JST
Received: by tansei.cc.u-tokyo.junet (1.2/6.3JunetInfoServer-1.0)
id AA12458; Mon, 20 Mar 89 19:33:59+0900
Date: Mon, 20 Mar 89 19:33:59+0900
From: Michitaka Hirose <a83338%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Return-Path: <a83338@tansei.cc.u-tokyo.junet>
Message-Id: <8903201033.AA12458@tansei.cc.u-tokyo.junet>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLUE on KCL
I'm using KCL(9/30/1987) on Sun3 and want to use CLUE.
But I can't compile CLUE(X11R3), so I suppose there must be patch for KCL.
Please send me a patch file, if it exsts.
Thank you very much.
------------
Hideki Koike (Information Engineering, University of Tokyo)
a83338%tansei.u-tokyo.junet%UTOKYO-RELAY.CSNET@RELAY.CS.NET
∂23-Mar-89 0915 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)
Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams. I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now. Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard. I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.
Issue: STREAM-DEFINITION-BY-USER
References: CLtL pages 329-332, 378-381, and 384-385.
Related issues: STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
STREAM-CAPABILITIES
Category: ADDITION
Edit history: Version 1, 22-Mar-89 by David N. Gray
Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.
Problem description:
Common Lisp does not provide a standard way for users to define their
own streams for use by the standard I/O functions. This impedes the
development of window systems for Common Lisp because, while there are
standard Common Lisp I/O functions and there are beginning to be
standard window systems, there is no portable way to connect them
together to make a portable Common Lisp window system.
There are also many applications where users might want to define
their own filter streams for doing things like printer device control,
report formatting, character code translation, or
encryption/decryption.
Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS
Overview:
Define a set of generic functions for performing I/O. These functions
will have methods that specialize on the stream argument; they would
be used by the existing I/O functions. Users could write additional
methods for them in order to support their own stream classes.
Define a set of classes to be used as the superclass of a stream class
in order to provide some default methods.
Classes:
The following classes are to be used as super classes of user-defined
stream classes. They are not intended to be directly instantiated; they
just provide places to hang default methods.
FUNDAMENTAL-STREAM [Class]
This class is a subclass of STREAM and of STANDARD-OBJECT. STREAMP
will return true for an instance of any class that includes this. (It
may return true for some other things also.)
FUNDAMENTAL-INPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes INPUT-STREAM-P
to return true.
FUNDAMENTAL-OUTPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes OUTPUT-STREAM-P
to return true. Bi-direction streams may be formed by including both
FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.
FUNDAMENTAL-CHARACTER-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. It provides a method for
STREAM-ELEMENT-TYPE which returns CHARACTER.
FUNDAMENTAL-BINARY-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Any instantiable class that
includes this needs to define a method for STREAM-ELEMENT-TYPE.
FUNDAMENTAL-CHARACTER-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character input.
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character output.
FUNDAMENTAL-BINARY-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
FUNDAMENTAL-BINARY-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
Character input:
A character input stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
generic functions below.
STREAM-READ-CHAR stream [Generic Function]
This reads one character from the stream. It returns either a
character object, or the symbol :EOF if the stream is at end-of-file.
Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
method for this function.
Note that for all of these generic functions, the stream argument
must be a stream object, not T or NIL.
STREAM-UNREAD-CHAR stream character [Generic Function]
Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR. Returns
NIL. Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
a method for this function.
STREAM-READ-CHAR-NO-HANG stream [Generic Function]
This is used to implement READ-CHAR-NO-HANG. It returns either a
character, or NIL if no input is currently available, or :EOF if
end-of-file is reached. The default method provided by
FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
is sufficient for file streams, but interactive streams should define
their own method.
STREAM-PEEK-CHAR stream [Generic Function]
Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
It returns either a character or :EOF. The default method
calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.
STREAM-LISTEN stream [Generic Function]
Used by LISTEN. Returns true or false. The default method uses
STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR. Most streams should
define their own method since it will usually be trivial and will
always be more efficient than the default method.
STREAM-READ-LINE stream [Generic Function]
Used by READ-LINE. A string is returned as the first value. The
second value is true if the string was terminated by end-of-file
instead of the end of a line. The default method uses repeated
calls to STREAM-READ-CHAR.
STREAM-CLEAR-INPUT stream [Generic Function]
Implements CLEAR-INPUT for the stream, returning NIL. The default
method does nothing.
Character output:
A character output stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
generic functions below.
STREAM-WRITE-CHAR stream character [Generic Function]
Writes character to the stream and returns the character. Every
subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
defined for this function.
STREAM-LINE-COLUMN stream [Generic Function]
This function returns the column number where the next character
will be written, or NIL if that is not meaningful for this stream.
The first column on a line is numbered 0. This function is used in
the implementation of PPRINT and the FORMAT ~T directive. For every
character output stream class that is defined, a method must be
defined for this function, although it is permissible for it to
always return NIL.
STREAM-START-LINE-P stream [Generic Function]
This is a predicate which returns T if the stream is positioned at the
beginning of a line, else NIL. It is permissible to always return
NIL. This is used in the implementation of FRESH-LINE. Note that
while a value of 0 from STREAM-LINE-COLUMN also indicates the
beginning of a line, there are cases where STREAM-START-LINE-P can be
meaningfully implemented although STREAM-LINE-COLUMN can't be. For
example, for a window using variable-width characters, the column
number isn't very meaningful, but the beginning of the line does have
a clear meaning. The default method for STREAM-START-LINE-P on class
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
that is defined to return NIL, then a method should be provided for
either STREAM-START-LINE-P or STREAM-FRESH-LINE.
STREAM-WRITE-STRING stream string &optional start end [Generic Function]
This is used by WRITE-STRING. It writes the string to the stream,
optionally delimited by start and end, which default to 0 and NIL.
The string argument is returned. The default method provided by
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
STREAM-WRITE-CHAR.
STREAM-TERPRI stream [Generic Function]
Writes an end of line, as for TERPRI. Returns NIL. The default
method does (STREAM-WRITE-CHAR stream #\NEWLINE).
STREAM-FRESH-LINE stream [Generic Function]
Used by FRESH-LINE. The default method uses STREAM-START-LINE-P and
STREAM-TERPRI.
STREAM-FINISH-OUTPUT stream [Generic Function]
Implements FINISH-OUTPUT. The default method does nothing.
STREAM-FORCE-OUTPUT stream [Generic Function]
Implements FORCE-OUTPUT. The default method does nothing.
STREAM-CLEAR-OUTPUT stream [Generic Function]
Implements CLEAR-OUTPUT. The default method does nothing.
STREAM-ADVANCE-TO-COLUMN stream column [Generic Function]
Writes enough blank space so that the next character will be written
at the specified column. Returns true if the operation is
successful, or NIL if it is not supported for this stream.
This is intended for use by by PPRINT and FORMAT ~T. The default
method uses STREAM-LINE-COLUMN and repeated calls to
STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
STREAM-LINE-COLUMN returns NIL.
Other functions:
CLOSE stream &key abort [Generic Function]
The existing function CLOSE is redefined to be a generic function, but
otherwise behaves the same. The default method provided by class
FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P. The value returned
by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.
OPEN-STREAM-P stream [Generic Function]
This function [from proposal STREAM-ACCESS] is made generic. A
default method is provided by class FUNDAMENTAL-STREAM which returns
true if CLOSE has not been called on the stream.
STREAMP object [Generic Function]
INPUT-STREAM-P stream [Generic Function]
OUTPUT-STREAM-P stream [Generic Function]
These three existing predicates may optionally be implemented as
generic functions for implementations that want to permit users to
define streams that are not STANDARD-OBJECTs. Normally, the default
methods provided by classes FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM are sufficient. Note that, for example,
(INPUT-STREAM-P x) is not equivalent to (TYPEP x
'FUNDAMENTAL-INPUT-STREAM) because implementations may have
additional ways of defining their own streams even if they don't
make that visible by making these predicates generic.
STREAM-ELEMENT-TYPE stream [Generic Function]
This existing function is made generic, but otherwise behaves the
same. Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
which returns CHARACTER.
PATHNAME and TRUENAME are also permitted to be implemented as generic
functions. There is no default method since these are not valid for
all streams.
Binary streams:
Binary streams can be created by defining a class that includes either
FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
(or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
both of the following generic functions.
STREAM-READ-BYTE stream [Generic Function]
Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
stream is at end-of-file.
STREAM-WRITE-BYTE stream integer [Generic Function]
Implements WRITE-BYTE; writes the integer to the stream and returns
the integer as the result.
Rationale:
The existing I/O functions cannot be made generic because, in nearly
every case, the stream argument is optional, and therefore cannot be
specialized. Therefore, it is necessary to define a lower-level
generic function to be used by the existing function. It also isn't
appropriate to specialize on the second argument of PRINT-OBJECT because
it is a higher-level function -- even when the first argument is a
character or a string, it needs to format it in accordance with
*PRINT-ESCAPE*.
In order to make the meaning as obvious as possible, the names of the
generic functions have been formed by prefixing "STREAM-" to the
corresponding non-generic function.
Having the generic input functions just return :EOF at end-of-file, with
the higher-level functions handling the eof-error-p and eof-value
arguments, simplifies the generic function interface and makes it more
efficient by not needing to pass through those arguments. Note that the
functions that use this convention can only return a character or
integer as a stream element, so there is no possibility of ambiguity.
Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
defeated proposal STREAM-INFO, but the motivation here is different.
This interface needs to be defined if user-defined streams are to be
able to be used by PPRINT and FORMAT ~T, which could be viewed as a
separate question from whether the user can call then on
system-defined streams.
Current practice:
No one currently supports exactly this proposal, but this is very
similar to the stream interface used in CLUE.
On descendants of the MIT Lisp Machine, streams can be implemented
by users as either flavors, with methods to accept the various
messages corresponding to the I/O operations, or as functions, which
take a message keyword as their first argument.
Examples:
;;;; Here is an example of how the default methods could be
;;;; implemented (omitting the most trivial ones):
(defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
(let ((character (stream-read-char stream)))
(unless (eq character :eof)
(stream-unread-char stream character))
character))
(defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
(let ((char (stream-read-char-no-hang stream)))
(and (not (null char))
(not (eq char :eof))
(progn (stream-unread-char stream char) t))))
(defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
(let ((line (make-array 64 :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(loop (let ((character (stream-read-char stream)))
(if (eq character :eof)
(return (values line t))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line)))))))
(defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
(equal (stream-line-column stream) 0))
(defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
string &optional (start 0)
(end (length string)))
(do ((i start (1+ i)))
((>= i end) string)
(stream-write-char stream (char string i))))
(defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
(stream-write-char stream #\newline)
nil)
(defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t)))
(defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream)
column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column) t)
(stream-write-char stream #\space)))))
(defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
(defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
;; allow the two classes to be mixed in either order
(typep stream 'fundamental-input-stream))
(defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
(defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
(typep stream 'fundamental-output-stream))
;;;; Following is an example of how the existing I/O functions could
;;;; be implemented using standard Common Lisp and the generic
;;;; functions specified above. The standard functions being defined
;;;; are in upper case.
;; Internal helper functions
(proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
(defun check-for-eof (value stream eof-errorp eof-value)
(if (eq value :eof)
(report-eof stream eof-errorp eof-value)
value))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; a mistake in CLtL?
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
(loop
(let ((value (stream-peek-char stream)))
(if (eq value :eof)
(return (report-eof stream eof-errorp eof-value))
(if (if (eq peek-type t)
(not (member value '(#\space #\tab #\newline
#\page #\return #\linefeed)))
(char= peek-type value))
(return value)
(stream-read-char stream))))))))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(multiple-value-bind (string eofp)
(stream-read-line stream)
(if eofp
(if (= (length string) 0)
(report-eof stream eof-error-p eof-value)
(values string t))
(values string nil)))))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char-no-hang stream)
stream eof-errorp eof-value)))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun TERPRI (&optional output-stream)
(stream-terpri (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
;;; Binary streams
(defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
(check-for-eof (stream-read-byte binary-input-stream)
binary-input-stream eof-errorp eof-value))
(defun WRITE-BYTE (integer binary-output-stream)
(stream-write-byte binary-output-stream integer))
;;; String streams
(defclass string-input-stream (fundamental-character-input-stream)
((string :initarg :string :type string)
(index :initarg :start :type fixnum)
(end :initarg :end :type fixnum)
))
(defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
(make-instance 'string-input-stream :string string
:start start :end (or end (length string))))
(defmethod stream-read-char ((stream string-input-stream))
(with-slots (index end string) stream
(if (>= index end)
:eof
(prog1 (char string index)
(incf index)))))
(defmethod stream-unread-char ((stream string-input-stream) character)
(with-slots (index end string) stream
(decf index)
(assert (eql (char string index) character))
nil))
(defmethod stream-read-line ((stream string-input-stream))
(with-slots (index end string) stream
(let* ((endline (position #\newline string :start index :end end))
(line (subseq string index endline)))
(if endline
(progn (setq index (1+ endline))
(values line nil))
(progn (setq index end)
(values line t))))))
(defclass string-output-stream (fundamental-character-output-stream)
((string :initform nil :initarg :string)))
(defun MAKE-STRING-OUTPUT-STREAM ()
(make-instance 'string-output-stream))
(defun GET-OUTPUT-STREAM-STRING (stream)
(with-slots (string) stream
(if (null string)
""
(prog1 string (setq string nil)))))
(defmethod stream-write-char ((stream string-output-stream) character)
(with-slots (string) stream
(when (null string)
(setq string (make-array 64. :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(vector-push-extend character string)
character))
(defmethod stream-line-column ((stream string-output-stream))
(with-slots (string) stream
(if (null string)
0
(let ((nx (position #\newline string :from-end t)))
(if (null nx)
(length string)
(- (length string) nx 1))
))))
Cost to Implementors:
Given that CLOS is supported, adding the above generic functions and
methods is easy, since most of the code is included in the examples
above. The hard part would be re-writing existing I/O functionality in
terms of methods on these new generic functions. That could be
simplified if methods can be defined to forward the operations to the
old representation of streams. For a new implementation, the cost could
be zero since an approach similar to this would likely be used anyway.
Cost to Users:
None; this is an upward-compatible addition. Users won't even
need to know anything about this unless they actually need this feature.
Cost of non-adoption:
Development of portable I/O extensions will be discouraged.
Performance impact:
This shouldn't affect performance of new implementations (assuming an
efficient CLOS implementation), but it could slow down I/O if it were
clumsily grafted on top of an existing implementation.
Benefits:
A broader domain of programs that can be written portably.
Esthetics:
This seems to be a simple, straight-forward approach.
Discussion:
This proposal incorporates suggestions made by several people in
response to an earlier outline. So far, no one has expressed opposition
to the concept. There are some differences of opinion about whether
certain operations should have default methods or required methods:
STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
and STREAM-START-LINE-P.
An experimental prototype of this has been successfully implemented on
the Explorer.
This proposal does not provide sufficient capability to implement
forwarding streams such as for MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
MAKE-ECHO-STREAM. The generic function approach does not lend itself as
well to that as a message passing model where the intermediary does not
need to know what all the possible messages are. A possible way of
extending it for that would be to define a class
(defclass stream-generic-function (standard-generic-function) ())
to be used as the :generic-function-class option for all of the I/O
generic functions. This would then permit doing something like
(defmethod no-applicable-method ((gfun stream-generic-function) &rest args)
(if (streamp (first args))
(apply #'stream-operation-not-handled (first args) gfun (rest args))
(call-next-method)))
where stream-operation-not-handled is a generic function whose default
method signals an error, but forwarding streams can define methods that
will create a method to handle the unexpected operation. (Perhaps
NO-APPLICABLE-METHOD should be changed to take two required arguments
since all generic functions need at least one required argument, and
that would make it unnecessary to define a new generic function class
just to be able to write this one method.)
Another thing that is not addressed here is a way to cause an instance
of a user-defined stream class to be created from a call to the OPEN
function. That should be part of a separate issue for generic functions
on pathnames. If that capability were available, then PATHNAME and
TRUENAME should be required to be generic functions.
An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
streams. It isn't clear whether that simple approach is sufficient or
whether the larger set of classes is really needed.
∂23-Mar-89 1503 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)
Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams. I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now. Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard. I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.
Issue: STREAM-DEFINITION-BY-USER
References: CLtL pages 329-332, 378-381, and 384-385.
Related issues: STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
STREAM-CAPABILITIES
Category: ADDITION
Edit history: Version 1, 22-Mar-89 by David N. Gray
Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.
Problem description:
Common Lisp does not provide a standard way for users to define their
own streams for use by the standard I/O functions. This impedes the
development of window systems for Common Lisp because, while there are
standard Common Lisp I/O functions and there are beginning to be
standard window systems, there is no portable way to connect them
together to make a portable Common Lisp window system.
There are also many applications where users might want to define
their own filter streams for doing things like printer device control,
report formatting, character code translation, or
encryption/decryption.
Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS
Overview:
Define a set of generic functions for performing I/O. These functions
will have methods that specialize on the stream argument; they would
be used by the existing I/O functions. Users could write additional
methods for them in order to support their own stream classes.
Define a set of classes to be used as the superclass of a stream class
in order to provide some default methods.
Classes:
The following classes are to be used as super classes of user-defined
stream classes. They are not intended to be directly instantiated; they
just provide places to hang default methods.
FUNDAMENTAL-STREAM [Class]
This class is a subclass of STREAM and of STANDARD-OBJECT. STREAMP
will return true for an instance of any class that includes this. (It
may return true for some other things also.)
FUNDAMENTAL-INPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes INPUT-STREAM-P
to return true.
FUNDAMENTAL-OUTPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes OUTPUT-STREAM-P
to return true. Bi-direction streams may be formed by including both
FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.
FUNDAMENTAL-CHARACTER-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. It provides a method for
STREAM-ELEMENT-TYPE which returns CHARACTER.
FUNDAMENTAL-BINARY-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Any instantiable class that
includes this needs to define a method for STREAM-ELEMENT-TYPE.
FUNDAMENTAL-CHARACTER-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character input.
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character output.
FUNDAMENTAL-BINARY-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
FUNDAMENTAL-BINARY-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
Character input:
A character input stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
generic functions below.
STREAM-READ-CHAR stream [Generic Function]
This reads one character from the stream. It returns either a
character object, or the symbol :EOF if the stream is at end-of-file.
Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
method for this function.
Note that for all of these generic functions, the stream argument
must be a stream object, not T or NIL.
STREAM-UNREAD-CHAR stream character [Generic Function]
Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR. Returns
NIL. Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
a method for this function.
STREAM-READ-CHAR-NO-HANG stream [Generic Function]
This is used to implement READ-CHAR-NO-HANG. It returns either a
character, or NIL if no input is currently available, or :EOF if
end-of-file is reached. The default method provided by
FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
is sufficient for file streams, but interactive streams should define
their own method.
STREAM-PEEK-CHAR stream [Generic Function]
Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
It returns either a character or :EOF. The default method
calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.
STREAM-LISTEN stream [Generic Function]
Used by LISTEN. Returns true or false. The default method uses
STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR. Most streams should
define their own method since it will usually be trivial and will
always be more efficient than the default method.
STREAM-READ-LINE stream [Generic Function]
Used by READ-LINE. A string is returned as the first value. The
second value is true if the string was terminated by end-of-file
instead of the end of a line. The default method uses repeated
calls to STREAM-READ-CHAR.
STREAM-CLEAR-INPUT stream [Generic Function]
Implements CLEAR-INPUT for the stream, returning NIL. The default
method does nothing.
Character output:
A character output stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
generic functions below.
STREAM-WRITE-CHAR stream character [Generic Function]
Writes character to the stream and returns the character. Every
subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
defined for this function.
STREAM-LINE-COLUMN stream [Generic Function]
This function returns the column number where the next character
will be written, or NIL if that is not meaningful for this stream.
The first column on a line is numbered 0. This function is used in
the implementation of PPRINT and the FORMAT ~T directive. For every
character output stream class that is defined, a method must be
defined for this function, although it is permissible for it to
always return NIL.
STREAM-START-LINE-P stream [Generic Function]
This is a predicate which returns T if the stream is positioned at the
beginning of a line, else NIL. It is permissible to always return
NIL. This is used in the implementation of FRESH-LINE. Note that
while a value of 0 from STREAM-LINE-COLUMN also indicates the
beginning of a line, there are cases where STREAM-START-LINE-P can be
meaningfully implemented although STREAM-LINE-COLUMN can't be. For
example, for a window using variable-width characters, the column
number isn't very meaningful, but the beginning of the line does have
a clear meaning. The default method for STREAM-START-LINE-P on class
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
that is defined to return NIL, then a method should be provided for
either STREAM-START-LINE-P or STREAM-FRESH-LINE.
STREAM-WRITE-STRING stream string &optional start end [Generic Function]
This is used by WRITE-STRING. It writes the string to the stream,
optionally delimited by start and end, which default to 0 and NIL.
The string argument is returned. The default method provided by
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
STREAM-WRITE-CHAR.
STREAM-TERPRI stream [Generic Function]
Writes an end of line, as for TERPRI. Returns NIL. The default
method does (STREAM-WRITE-CHAR stream #\NEWLINE).
STREAM-FRESH-LINE stream [Generic Function]
Used by FRESH-LINE. The default method uses STREAM-START-LINE-P and
STREAM-TERPRI.
STREAM-FINISH-OUTPUT stream [Generic Function]
Implements FINISH-OUTPUT. The default method does nothing.
STREAM-FORCE-OUTPUT stream [Generic Function]
Implements FORCE-OUTPUT. The default method does nothing.
STREAM-CLEAR-OUTPUT stream [Generic Function]
Implements CLEAR-OUTPUT. The default method does nothing.
STREAM-ADVANCE-TO-COLUMN stream column [Generic Function]
Writes enough blank space so that the next character will be written
at the specified column. Returns true if the operation is
successful, or NIL if it is not supported for this stream.
This is intended for use by by PPRINT and FORMAT ~T. The default
method uses STREAM-LINE-COLUMN and repeated calls to
STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
STREAM-LINE-COLUMN returns NIL.
Other functions:
CLOSE stream &key abort [Generic Function]
The existing function CLOSE is redefined to be a generic function, but
otherwise behaves the same. The default method provided by class
FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P. The value returned
by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.
OPEN-STREAM-P stream [Generic Function]
This function [from proposal STREAM-ACCESS] is made generic. A
default method is provided by class FUNDAMENTAL-STREAM which returns
true if CLOSE has not been called on the stream.
STREAMP object [Generic Function]
INPUT-STREAM-P stream [Generic Function]
OUTPUT-STREAM-P stream [Generic Function]
These three existing predicates may optionally be implemented as
generic functions for implementations that want to permit users to
define streams that are not STANDARD-OBJECTs. Normally, the default
methods provided by classes FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM are sufficient. Note that, for example,
(INPUT-STREAM-P x) is not equivalent to (TYPEP x
'FUNDAMENTAL-INPUT-STREAM) because implementations may have
additional ways of defining their own streams even if they don't
make that visible by making these predicates generic.
STREAM-ELEMENT-TYPE stream [Generic Function]
This existing function is made generic, but otherwise behaves the
same. Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
which returns CHARACTER.
PATHNAME and TRUENAME are also permitted to be implemented as generic
functions. There is no default method since these are not valid for
all streams.
Binary streams:
Binary streams can be created by defining a class that includes either
FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
(or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
both of the following generic functions.
STREAM-READ-BYTE stream [Generic Function]
Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
stream is at end-of-file.
STREAM-WRITE-BYTE stream integer [Generic Function]
Implements WRITE-BYTE; writes the integer to the stream and returns
the integer as the result.
Rationale:
The existing I/O functions cannot be made generic because, in nearly
every case, the stream argument is optional, and therefore cannot be
specialized. Therefore, it is necessary to define a lower-level
generic function to be used by the existing function. It also isn't
appropriate to specialize on the second argument of PRINT-OBJECT because
it is a higher-level function -- even when the first argument is a
character or a string, it needs to format it in accordance with
*PRINT-ESCAPE*.
In order to make the meaning as obvious as possible, the names of the
generic functions have been formed by prefixing "STREAM-" to the
corresponding non-generic function.
Having the generic input functions just return :EOF at end-of-file, with
the higher-level functions handling the eof-error-p and eof-value
arguments, simplifies the generic function interface and makes it more
efficient by not needing to pass through those arguments. Note that the
functions that use this convention can only return a character or
integer as a stream element, so there is no possibility of ambiguity.
Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
defeated proposal STREAM-INFO, but the motivation here is different.
This interface needs to be defined if user-defined streams are to be
able to be used by PPRINT and FORMAT ~T, which could be viewed as a
separate question from whether the user can call then on
system-defined streams.
Current practice:
No one currently supports exactly this proposal, but this is very
similar to the stream interface used in CLUE.
On descendants of the MIT Lisp Machine, streams can be implemented
by users as either flavors, with methods to accept the various
messages corresponding to the I/O operations, or as functions, which
take a message keyword as their first argument.
Examples:
;;;; Here is an example of how the default methods could be
;;;; implemented (omitting the most trivial ones):
(defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
(let ((character (stream-read-char stream)))
(unless (eq character :eof)
(stream-unread-char stream character))
character))
(defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
(let ((char (stream-read-char-no-hang stream)))
(and (not (null char))
(not (eq char :eof))
(progn (stream-unread-char stream char) t))))
(defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
(let ((line (make-array 64 :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(loop (let ((character (stream-read-char stream)))
(if (eq character :eof)
(return (values line t))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line)))))))
(defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
(equal (stream-line-column stream) 0))
(defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
string &optional (start 0)
(end (length string)))
(do ((i start (1+ i)))
((>= i end) string)
(stream-write-char stream (char string i))))
(defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
(stream-write-char stream #\newline)
nil)
(defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t)))
(defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream)
column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column) t)
(stream-write-char stream #\space)))))
(defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
(defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
;; allow the two classes to be mixed in either order
(typep stream 'fundamental-input-stream))
(defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
(defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
(typep stream 'fundamental-output-stream))
;;;; Following is an example of how the existing I/O functions could
;;;; be implemented using standard Common Lisp and the generic
;;;; functions specified above. The standard functions being defined
;;;; are in upper case.
;; Internal helper functions
(proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
(defun check-for-eof (value stream eof-errorp eof-value)
(if (eq value :eof)
(report-eof stream eof-errorp eof-value)
value))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; a mistake in CLtL?
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
(loop
(let ((value (stream-peek-char stream)))
(if (eq value :eof)
(return (report-eof stream eof-errorp eof-value))
(if (if (eq peek-type t)
(not (member value '(#\space #\tab #\newline
#\page #\return #\linefeed)))
(char= peek-type value))
(return value)
(stream-read-char stream))))))))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(multiple-value-bind (string eofp)
(stream-read-line stream)
(if eofp
(if (= (length string) 0)
(report-eof stream eof-error-p eof-value)
(values string t))
(values string nil)))))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char-no-hang stream)
stream eof-errorp eof-value)))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun TERPRI (&optional output-stream)
(stream-terpri (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
;;; Binary streams
(defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
(check-for-eof (stream-read-byte binary-input-stream)
binary-input-stream eof-errorp eof-value))
(defun WRITE-BYTE (integer binary-output-stream)
(stream-write-byte binary-output-stream integer))
;;; String streams
(defclass string-input-stream (fundamental-character-input-stream)
((string :initarg :string :type string)
(index :initarg :start :type fixnum)
(end :initarg :end :type fixnum)
))
(defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
(make-instance 'string-input-stream :string string
:start start :end (or end (length string))))
(defmethod stream-read-char ((stream string-input-stream))
(with-slots (index end string) stream
(if (>= index end)
:eof
(prog1 (char string index)
(incf index)))))
(defmethod stream-unread-char ((stream string-input-stream) character)
(with-slots (index end string) stream
(decf index)
(assert (eql (char string index) character))
nil))
(defmethod stream-read-line ((stream string-input-stream))
(with-slots (index end string) stream
(let* ((endline (position #\newline string :start index :end end))
(line (subseq string index endline)))
(if endline
(progn (setq index (1+ endline))
(values line nil))
(progn (setq index end)
(values line t))))))
(defclass string-output-stream (fundamental-character-output-stream)
((string :initform nil :initarg :string)))
(defun MAKE-STRING-OUTPUT-STREAM ()
(make-instance 'string-output-stream))
(defun GET-OUTPUT-STREAM-STRING (stream)
(with-slots (string) stream
(if (null string)
""
(prog1 string (setq string nil)))))
(defmethod stream-write-char ((stream string-output-stream) character)
(with-slots (string) stream
(when (null string)
(setq string (make-array 64. :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(vector-push-extend character string)
character))
(defmethod stream-line-column ((stream string-output-stream))
(with-slots (string) stream
(if (null string)
0
(let ((nx (position #\newline string :from-end t)))
(if (null nx)
(length string)
(- (length string) nx 1))
))))
Cost to Implementors:
Given that CLOS is supported, adding the above generic functions and
methods is easy, since most of the code is included in the examples
above. The hard part would be re-writing existing I/O functionality in
terms of methods on these new generic functions. That could be
simplified if methods can be defined to forward the operations to the
old representation of streams. For a new implementation, the cost could
be zero since an approach similar to this would likely be used anyway.
Cost to Users:
None; this is an upward-compatible addition. Users won't even
need to know anything about this unless they actually need this feature.
Cost of non-adoption:
Development of portable I/O extensions will be discouraged.
Performance impact:
This shouldn't affect performance of new implementations (assuming an
efficient CLOS implementation), but it could slow down I/O if it were
clumsily grafted on top of an existing implementation.
Benefits:
A broader domain of programs that can be written portably.
Esthetics:
This seems to be a simple, straight-forward approach.
Discussion:
This proposal incorporates suggestions made by several people in
response to an earlier outline. So far, no one has expressed opposition
to the concept. There are some differences of opinion about whether
certain operations should have default methods or required methods:
STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
and STREAM-START-LINE-P.
An experimental prototype of this has been successfully implemented on
the Explorer.
This proposal does not provide sufficient capability to implement
forwarding streams such as for MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
MAKE-ECHO-STREAM. The generic function approach does not lend itself as
well to that as a message passing model where the intermediary does not
need to know what all the possible messages are. A possible way of
extending it for that would be to define a class
(defclass stream-generic-function (standard-generic-function) ())
to be used as the :generic-function-class option for all of the I/O
generic functions. This would then permit doing something like
(defmethod no-applicable-method ((gfun stream-generic-function) &rest args)
(if (streamp (first args))
(apply #'stream-operation-not-handled (first args) gfun (rest args))
(call-next-method)))
where stream-operation-not-handled is a generic function whose default
method signals an error, but forwarding streams can define methods that
will create a method to handle the unexpected operation. (Perhaps
NO-APPLICABLE-METHOD should be changed to take two required arguments
since all generic functions need at least one required argument, and
that would make it unnecessary to define a new generic function class
just to be able to write this one method.)
Another thing that is not addressed here is a way to cause an instance
of a user-defined stream class to be created from a call to the OPEN
function. That should be part of a separate issue for generic functions
on pathnames. If that capability were available, then PATHNAME and
TRUENAME should be required to be generic functions.
An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
streams. It isn't clear whether that simple approach is sufficient or
whether the larger set of classes is really needed.
∂30-Mar-89 1656 CL-Windows-mailer improved version of CLX available
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 30 Mar 89 16:55:19 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA17857; Thu, 30 Mar 89 16:29:41 -0800
Received: from sparky by franz (3.2/3.14)
id AA22089; Thu, 30 Mar 89 16:08:50 PST
Received: by sparky (4.0/3.14)
id AA04082; Thu, 30 Mar 89 16:08:33 PST
Return-Path: <sparky!jdi>
Message-Id: <8903310008.AA04082@sparky>
To: franz!zermatt.lcs.mit.edu!bug-clx, franz!sail.stanford.edu!cl-windows
Subject: improved version of CLX available
Date: Thu, 30 Mar 89 16:08:31 -0800
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
An improved version of X11.R3 CLX is available via public ftp on:
ucbarpa (10.0.0.78, 128.32.130.11)
in ~ftp/pub/clx.tar.Z
This version of CLX is essentially Release 3 with all the reported
bugs fixed. There are also many enhancements specific to Franz
Allegro Common Lisp, including a large speedup and integration with
the Pitman condition system. All of the Allegro specific changes are #+excl
or #+allegro. This version (the April Fools Day CLX?) should be completely
compatible with the R3 version, minus the bugs and race conditions.
The complete list of changes is at the end of this message. One known
fix that didn't make it in was Judy Anderson's patch for Lucid 3.0. The
diff listings provided with that patch were from release 2.
(I would appreciate it if someone can provides diffs from R3)
-- John Irwin, jdi%franz.uucp@ucbarpa.berkeley.edu
------ the file NEWCHANGES ------
This file contains a full list of the differences between X11.R3 CLX and this
version. Effort was made to ensure that this version is completely compatible
with the R3 version; thus this version should compile and run on the same set
of Lisps as the R3 version. Some of the changes in this version are specific
to Allegro Common Lisp, but these changes are #+allegro or #+excl.
General changes, applicable to all ports:
----------------------------------------
LaMott's fix to unset display-waiting-reply-p correctly. My fix to
make sure it isn't unset before its time.
-- buffer.l: read-sequence-string
-- bufmac.l: reading-buffer-reply
reading-buffer-chunks
-- input.l: wait-for-reply
LaMott's unexporting of display-version-number, display-squish,
font-min-bounds, and font-max-bounds. Also removal of first two
from display defstruct. New exporting of char->card8 and card8->char.
Bad declaration in keycode->character fixed. Unused argument in
put-image removed.
-- clx.l: export list
display defstruct
-- dependent.l: export list
-- translate.l: keycode->character
-- image.l: put-image
Judy Anderson's fix to radians->int16 -- argument was declared as
float but sometimes the fixnum 0 was passed. Modified by me to
be more optimal on a greater number of CL implementations.
-- dependent.l :radians->int16
Error handling revamped by LaMott and me. New macro catching-errors
is like with-display, but also guarantees any server errors occuring
as a result of requests sent while inside the macro will be reported
in the current process. Report-error rewritten to discard or preserve
replies correctly. With-display rewritten to allow wait-for-event to
know when errors should be "forwarded" to another process which is
interested in them. Wait-for-event now forwards errors to process
waiting for a reply (if any).
-- display.l: export list
catching-errors (new function)
with-display
-- input.l: wait-for-event
report-error
LaMott's fix to make font accessors work correctly when font-min-char
is not 0
-- fonts.l: def-char-info-accessors
Bill Chile's fix to make draw-arcs terminate correctly.
-- graphics.l: draw-arcs
Fix to set display-dead before giving the server-disconnect error,
instead of after. (Since the error function probably won't return)
-- input.l: wait-for-event
Added new slots to normal-hints structure to make it more ICCCM
compliant. base-width, base-height, and win-gravity.
-- manager.l: export list
wm-size-hints defstruct
decode-wm-size-hints
encode-wm-size-hints
Send-event fixed to increment the buffer offset by the correct
amount. (It didn't work at all before)
-- requests.l: send-event
H. Kawabe's fix to print-resource, which didn't always print to
the correct stream. New initialize-resource-database function added.
(It isn't called or exported, just sample code.)
-- resource.l: print-resource
initialize-resource-database (new function)
Brain damaged code in keysym-shift-p caused the shift bit to be
inverted when a control character was input. LaMott says this is
the right behaviour for a lisp machine, but it isn't for a Lisp
that supports multicase, as Allegro does. I #+lispm'ed the offending
code.
-- translate.l: keysym-shift-p
Lamott's speed up of image functions copy-pixarray-row-1 and
read-bitmap-file. Fixed write-bitmap-file to work with images
with scanline pad != 32.
-- image.l: copy-pixarray-row-1
read-bitmap-file
write-bitmap-file
Put-image-z enhanced to be able to send image larger than the server
can accept in one shot. Write-bitmap-file optimized.
-- image.l: put-image-z
write-bitmap-file
Made debug files usable in mixed case lisps. Use warn if si:signal
is not available, etc. Note that lowercasification of trace.l was
a bit more zealous than necessary. (But was much easier than doing
the whole thing). Ash bug in trace fixed. New file proc-trace.l
added -- traces which process sends which request, etc
-- debug/debug.l
-- debug/describe.l
-- debug/trace.l
Franz specific changes, applicable to Allegro and Extended Common Lisps:
(note that all these changes are #+excl or #+allegro, so if you're not
using our product these changes are "commented" out)
-----------------------------------------------------------------------
Fix to make Allegro process-locks be created lazily. Holding-lock
also rewritten to be faster and smaller. Atomic-push and pop changed
to be "safe" in case CLX source is ever modified to use these functions
on a form. (Currently they're always used on a global)
-- dependent.l :#+excl make-process-lock
#+excl holding-lock
#+excl test-inside-event-listen (new function)
#+excl event-listen-error (function removed)
#+excl atomic-push
#+excl atomic-pop
Fix to make reading from the X socket work correcly on large
requests. Buffer-close-default declaration changed to not give
warning. C reading/writing code completely rewritten -- now only
requires select, not select and FIONREAD
-- dependent.l :#+excl buffer-read-default
#+excl buffer-close-default
-- excldep.c
CLX integrated with Allegro implemenation of Pitman condition system.
Moved request-error definition to after the request-error printer,
since Pitman wants it so.
-- dependent.l :#+excl x-error
#+excl x-cerror
#+excl x-error defstruct,
reporter-for-condition,
define-condition,
condition-print,
make-condition (all removed)
-- input.cl: #+excl request-error define-condition (moved)
Moved stuff out of defsystem into excldep, so defsystem doesn't
have to be catted into CLX.fasl.
-- excldefsys.l
-- excldep.l
-- exclMakefile
Very large speedup to type checking -- added compiler transform.
Copyright notice added to this file.
-- excldep.l
∂31-Mar-89 1301 CL-Windows-mailer Drowning in a vat of Clue?
Received: from rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 31 Mar 89 13:01:01 PST
Received: from [128.119.40.235] by rand.org; Fri, 31 Mar 89 11:52:54 PST
Received: from vax9.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA26136; Fri, 31 Mar 89 14:54:07 est
Message-Id: <8903311954.AA26136@crash.cs.umass.edu>
Date: Fri, 31 Mar 89 14:53 EST
From: BROLIO@cs.umass.EDU
Subject: Drowning in a vat of Clue?
To: lispx@rand.org
X-Vms-To: IN%"lispx@rand-unix.arpa"
I need help. I am using Experimental CLUE 4.0 with a preliminary
version of CLOS from TI. I seem to be in a maze of infinitely twisty
little bugs, which prevent me from doing anything serious after 6 weeks
of painful labor.
Examples:
1. Is BACKGROUND :PARENT-RELATIVE meaningful? I was using it and
noticed that it always gave you WHITE, whatever your parent was defined
to be. So I looked into the code. When I finally tracked down
SET-CONTACT-BACKGROUND, it looked to me like the code was hard-wired to
ignore :parent-relative. Is that the case? What about in C versions of
X?
2. What is the REAL behavior of initforms/args. I defined a contact
class called CONFORMING-LABEL, with superclass LABEL, like so.
(defcontact conforming-label (label)
()
(:resources
(style :initform :box)))
No change in STYLE. The only way I could get a change in STYLE, is to
patch the definition of LABEL, adding :initarg :style to the STYLE
resource list in the LABEL class. This doesn't seem quite right.
These are two of the bugs I have been able to isolate, but in fact,
whenever I try to do something slightly different from the DEMO, I get a
slew of X-errors of one sort or another which take some time to track
down. So my question is: are people using CLUE for serious window work,
or are they writing their own toolkits? In either case, is there any
wisdom or guidance to be had? Do I have an old version, or what?
John Brolio
Brolio@CS.UMASS.EDU
∂03-Apr-89 0428 CL-Windows-mailer A couple of Lisp and X products
Received: from oberon.usc.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89 04:28:16 PDT
Received: from loki.usc.edu by oberon.usc.edu (5.59/5.5) id AA11311;
Mon, 3 Apr 89 04:27:42 PST
Received: by loki.usc.edu (3.2/SMI-3.0DEV3) id AA08185;
Mon, 3 Apr 89 04:27:54 PDT
Date: Mon, 3 Apr 89 04:27:54 PDT
From: temin%loki.usc.edu@oberon.usc.edu (Aaron Eek Temin)
Message-Id: <8904031127.AA08185@loki.usc.edu>
To: cl-windows@sail.stanford.edu
Subject: A couple of Lisp and X products
I saw a couple of interesting products (well, saw 1, heard about the
other) here in D.C. last week: X Remote Screen from ILA, and Express
Windows from Liszt Programming, inc (Arlington, VA).
A fellow from ILA came to speak at the SLUG meeting. Among other
products (their port of the X server has been panned elsewhere) they
have a product that will allow code that usually talks to the
Symbolics' screen/keyboard to also talk to an X server with no code
modifications (eg., run the document examiner from a Sun). This one I
didn't get to see.
Liszt has a toolkit built on top of CLX. Supposedly provides much of
the same functionality as Symbolics, eg accepting-values. The demos
they showed looked a lot like a Symbolics screen, but it was running
on a Sun. They said that the calls looked a lot like those for a
Symbolics program to make it easy to (a) port an existing application,
or (b) write for X if you were familiar with Symbolics. They were
particularly proud of their quick screen updating.
-Aaron Temin
∂03-Apr-89 0807 CL-Windows-mailer having troubles with Clue
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 3 Apr 89 08:07:09 PDT
Received: from vax9.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA28500; Mon, 3 Apr 89 12:09:45 edt
Message-Id: <8904031609.AA28500@crash.cs.umass.edu>
Date: Mon, 3 Apr 89 11:09 EST
From: BROLIO@cs.umass.EDU
Subject: having troubles with Clue
To: cl-windows@sail.stanford.EDU
X-Vms-To: IN%"cl-windows@sail.stanford.edu"
I need help. I am using Experimental CLUE 4.0 with a preliminary
version of CLOS from TI. I seem to be in a maze of infinitely twisty
little bugs, which prevent me from doing anything serious after 6 weeks
of painful labor.
Examples:
1. Is BACKGROUND :PARENT-RELATIVE meaningful? I was using it and
noticed that it always gave you WHITE, whatever your parent was defined
to be. So I looked into the code. When I finally tracked down
SET-CONTACT-BACKGROUND, it looked to me like the code was hard-wired to
ignore :parent-relative. Is that the case? What about in C versions of
X?
2. What is the REAL behavior of initforms/args. I defined a contact
class called CONFORMING-LABEL, with superclass LABEL, like so.
(defcontact conforming-label (label)
()
(:resources
(style :initform :box)))
No change in STYLE. The only way I could get a change in STYLE, is to
patch the definition of LABEL, adding :initarg :style to the STYLE
resource list in the LABEL class. This doesn't seem quite right.
These are two of the bugs I have been able to isolate, but in fact,
whenever I try to do something slightly different from the DEMO, I get a
slew of X-errors of one sort or another which take some time to track
down. So my question is: are people using CLUE for serious window work,
or are they writing their own toolkits? In either case, is there any
wisdom or guidance to be had? Do I have an old version, or what?
John Brolio
Brolio@CS.UMASS.EDU
∂04-Apr-89 2217 CL-Windows-mailer Re: improved version of CLX available
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Apr 89 22:17:30 PDT
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA17292g; Tue, 4 Apr 89 22:10:58 PDT
Received: by boston-harbor id AA00991g; Wed, 5 Apr 89 01:18:45 EDT
Date: Wed, 5 Apr 89 01:18:45 EDT
From: Judy Anderson <yduJ@lucid.com>
Message-Id: <8904050518.AA00991@boston-harbor>
To: franz!sparky!jdi@ucbarpa.berkeley.edu
Cc: bug-clx@zermatt.lcs.mit.edu, cl-windows@sail.stanford.edu
In-Reply-To: John Irwin's message of Thu, 30 Mar 89 16:08:31 -0800 <8903310008.AA04082@sparky>
Subject: Re: improved version of CLX available
Here is a copy of my recent locking + Lucid IO speedup patch made for
CLX R3, in theory in a format acceptable to the patch program. Lucid
IO speedups are all in dependent.l. More process locking is in the
other files. The files are in alphabetical order in this message.
This patch is only for R3; the previous version sent out was for R2.
If you applied the R2 patch to R3 (which works sort of; you have to
edit the patch a little bit) don't apply this one...
yduJ (Judy Anderson)
Lucid East
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
---------------------------------------------------------------------------
*** /x11-r3/lib/CLX/attributes.l Wed Mar 16 12:27:11 1988
--- /x11r3/lucid-clx/attributes.lisp Mon Mar 6 14:03:28 1989
***************
*** 269,288 ****
(deallocate-gcontext-state (state-geometry-changes state-entry))
(setf (state-geometry-changes state-entry) nil))
;; Get drawable attributes
! (with-buffer-request (display *x-getgeometry* :no-after)
! (drawable drawable))
! (let ((buffer (or (state-geometry state-entry)
! (allocate-context))))
! (wait-for-reply display *geometry-size*)
! ;; Copy into event from reply buffer
! (buffer-replace (reply-ibuf8 buffer)
! (reply-ibuf8 (buffer-reply-buffer display))
! 0
! *geometry-size*)
! (when state-entry
! (setf (state-geometry state-entry) buffer))
! (display-invoke-after-function display)
! buffer))))))
(defun put-window-attribute-changes (window changes)
;; change window attributes
--- 269,289 ----
(deallocate-gcontext-state (state-geometry-changes state-entry))
(setf (state-geometry-changes state-entry) nil))
;; Get drawable attributes
! (with-input-lock (display)
! (with-buffer-request (display *x-getgeometry* :no-after)
! (drawable drawable))
! (let ((buffer (or (state-geometry state-entry)
! (allocate-context))))
! (wait-for-reply display *geometry-size*)
! ;; Copy into event from reply buffer
! (buffer-replace (reply-ibuf8 buffer)
! (reply-ibuf8 (buffer-reply-buffer display))
! 0
! *geometry-size*)
! (when state-entry
! (setf (state-geometry state-entry) buffer))
! (display-invoke-after-function display)
! buffer)))))))
(defun put-window-attribute-changes (window changes)
;; change window attributes
*** /x11-r3/lib/CLX/dependent.l Sat Oct 22 10:43:42 1988
--- /x11r3/lucid-clx/dependent.lisp Mon Mar 6 14:02:50 1989
***************
*** 479,488 ****
(defun radians->int16 (value)
;; Short floats are good enough
! (declare (type float value))
(declare-values int16)
(declare-buffun)
! (the int16 (identity (round (* value 180.0s0 64.0s0) #.(coerce pi 'short-float)))))
(defun int16->radians (value)
;; Short floats are good enough
--- 479,490 ----
(defun radians->int16 (value)
;; Short floats are good enough
! ;; Note that this gets called with integer zero sometimes and not all
! ;; implementations will have integer zero and float zero the same... --yduJ
! ; (declare (type float value))
(declare-values int16)
(declare-buffun)
! (the int16 (identity (round (* (float value) 180.0s0 64.0s0) #.(coerce pi 'short-float)))))
(defun int16->radians (value)
;; Short floats are good enough
***************
*** 1035,1046 ****
(c-read-bytes fd vector start howmany)
)))))))))))))
;;; WARNING:
;;; CLX performance will suffer if your lisp uses read-byte for
;;; receiving all data from the X Window System server.
;;; You are encouraged to write a specialized version of
;;; buffer-read-default that does block transfers.
! #-(or genera explorer excl)
(defmacro CL-read-bytes (stream vector start end)
`(do* ((i ,start (index+ i 1))
(c nil))
--- 1037,1110 ----
(c-read-bytes fd vector start howmany)
)))))))))))))
+ #+lcl3.0
+ (defmacro fast-read-bytes (stream vector start end)
+ `(do* ((i ,start (index+ i 1))
+ (c nil))
+ ((index>= i ,end) nil)
+ (declare (type array-index i)
+ (type (or null card8) c))
+ (setq c (lcl:fast-read-byte ,stream (unsigned-byte 8) nil nil))
+ (if c
+ (setf (aref ,vector i) c)
+ (return t))))
+
+ #+lcl3.0
+ (defmacro extract-underlying-stream (stream display direction)
+ ;;;Our job is to quickly get at the underlying stream for this display's
+ ;;;input stream structure.
+ `(or (getf (display-plist ,display) ,direction)
+ (setf (getf (display-plist ,display) ,direction)
+ (lucid::underlying-stream ,stream (if (eq ,direction 'input)
+ :input
+ :output)))))
+
+ #+lcl3.0
+ (defun buffer-read-default (display vector start end timeout)
+ ;;Note that LISTEN must still be done on "slow stream" or the I/O system
+ ;;gets confused. But reading should be done from "fast stream" for speed.
+ ;;We inhibit scheduling when reading because there seem to be races in
+ ;;Lucid's multitasking implementation.
+ (declare (type display display)
+ (type buffer-bytes vector)
+ (type array-index start end)
+ (type (or null number) timeout)
+ (optimize (speed 3)
+ (safety 0)))
+ (let* ((stream (display-input-stream display))
+ (fast-stream (extract-underlying-stream stream display 'input)))
+ (cond ((or (null timeout)
+ (listen stream))
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ nil) ;return NIL, it expects that
+ ((or (minusp timeout) (zerop timeout))
+ ;;negative timeout means try once, Jerry's hack. Zerop seems
+ ;;to *also* mean try once; don't understand why Jerry wanted -1.
+ (if (listen stream)
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ :timeout))
+ (timeout ;otherwise we have a bona-fide timeout on our hands which
+ ;we should wait for.
+ (let ((input-appeared
+ (lucid::waiting-for-input-from-stream fast-stream
+ (lucid::with-io-unlocked
+ (lcl:process-wait-with-timeout
+ "Waiting for CLX server response"
+ timeout #'listen stream)))))
+ (if input-appeared
+ (lcl:with-scheduling-inhibited
+ (fast-read-bytes fast-stream vector start end))
+ :timeout))))))
+
+
;;; WARNING:
;;; CLX performance will suffer if your lisp uses read-byte for
;;; receiving all data from the X Window System server.
;;; You are encouraged to write a specialized version of
;;; buffer-read-default that does block transfers.
! #-(or genera explorer excl lcl3.0)
(defmacro CL-read-bytes (stream vector start end)
`(do* ((i ,start (index+ i 1))
(c nil))
***************
*** 1053,1062 ****
(return t))))
;; Poll for input every *buffer-read-polling-time* SECONDS.
! #-(or genera explorer excl)
(defparameter *buffer-read-polling-time* 0.5)
! #-(or genera explorer excl)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
--- 1117,1126 ----
(return t))))
;; Poll for input every *buffer-read-polling-time* SECONDS.
! #-(or genera explorer excl lcl3.0)
(defparameter *buffer-read-polling-time* 0.5)
! #-(or genera explorer excl lcl3.0)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
***************
*** 1104,1109 ****
--- 1168,1189 ----
vector start end)))
(error "X write failed: socket dead!")))
+ #+lcl3.0
+ (defun buffer-write-default (vector display start end)
+ ;;We inhibit scheduling here because there seem to be races in Lucid's
+ ;;multitasking implementation. Anyway, when we take it out we get bugs!
+ (declare (type display display)
+ (type buffer-bytes vector)
+ (type array-index start end)
+ (optimize (:tail-merge nil)
+ (speed 3)
+ (safety 0)))
+ (lcl:with-scheduling-inhibited
+ (lcl:write-array
+ (extract-underlying-stream
+ (display-output-stream display) display 'output)
+ vector start end)))
+
;;; WARNING:
;;; CLX performance will be severely degraded if your lisp uses
;;; write-byte to send all data to the X Window System server.
***************
*** 1110,1116 ****
;;; You are STRONGLY encouraged to write a specialized version
;;; of buffer-write-default that does block transfers.
! #-(or genera explorer excl)
(defun buffer-write-default (vector display start end)
;; The default buffer write function for use with common-lisp streams
(declare (type buffer-bytes vector)
--- 1190,1196 ----
;;; You are STRONGLY encouraged to write a specialized version
;;; of buffer-write-default that does block transfers.
! #-(or genera explorer excl lcl3.0)
(defun buffer-write-default (vector display start end)
;; The default buffer write function for use with common-lisp streams
(declare (type buffer-bytes vector)
*** /x11-r3/lib/CLX/graphics.l Thu Aug 11 17:34:28 1988
--- /x11r3/lucid-clx/graphics.lisp Mon Mar 6 14:03:15 1989
***************
*** 421,437 ****
(let ((display (drawable-display drawable))
seq depth visual)
(with-display (display)
! (with-buffer-request (display *x-getimage* :no-after)
! ((data (member error :xy-pixmap :z-pixmap)) format)
! (drawable drawable)
! (int16 x y)
! (card16 width height)
! (card32 plane-mask))
! (with-buffer-reply (display nil :sizes (8 32))
! (setq depth (card8-get 1)
! visual (resource-id-get 8))
! (let ((length (* 4 (card32-get 4))))
! (setq seq (sequence-get :result-type result-type :format card8
! :length length :start start :data data)))))
(display-invoke-after-function display)
(values seq depth visual)))
--- 421,438 ----
(let ((display (drawable-display drawable))
seq depth visual)
(with-display (display)
! (with-input-lock (display)
! (with-buffer-request (display *x-getimage* :no-after)
! ((data (member error :xy-pixmap :z-pixmap)) format)
! (drawable drawable)
! (int16 x y)
! (card16 width height)
! (card32 plane-mask))
! (with-buffer-reply (display nil :sizes (8 32))
! (setq depth (card8-get 1)
! visual (resource-id-get 8))
! (let ((length (* 4 (card32-get 4))))
! (setq seq (sequence-get :result-type result-type :format card8
! :length length :start start :data data))))))
(display-invoke-after-function display)
(values seq depth visual)))
*** /x11-r3/lib/CLX/macros.l Tue Aug 30 07:58:24 1988
--- /x11r3/lucid-clx/macros.lisp Mon Mar 6 14:03:11 1989
***************
*** 725,733 ****
(declare-arglist (buffer &optional size &key sizes) &body body)
(let ((buf (gensym)))
`(let ((,buf ,buffer))
! (wait-for-reply ,buf ,size)
! (reading-buffer-reply (,buf ,@options)
! ,@body))))
(defmacro compare-request ((index) &body body)
`(macrolet ((write-card32 (index item) `(= ,item (read-card32 ,index)))
--- 725,735 ----
(declare-arglist (buffer &optional size &key sizes) &body body)
(let ((buf (gensym)))
`(let ((,buf ,buffer))
! ;;;This better always be called with a display.
! (with-input-lock (,buf)
! (wait-for-reply ,buf ,size)
! (reading-buffer-reply (,buf ,@options)
! ,@body)))))
(defmacro compare-request ((index) &body body)
`(macrolet ((write-card32 (index item) `(= ,item (read-card32 ,index)))
*** /x11-r3/lib/CLX/requests.l Sat Sep 3 06:59:22 1988
--- /x11r3/lucid-clx/requests.lisp Mon Mar 6 14:03:07 1989
***************
*** 1086,1092 ****
(declare (type colormap colormap)
(type card16 colors planes)
(type boolean contiguous-p)
! (type t result-type)) ;; CL type
(declare-values (sequence pixel) (sequence mask))
(let ((display (colormap-display colormap))
pixel-sequence mask-sequence)
--- 1086,1092 ----
(declare (type colormap colormap)
(type card16 colors planes)
(type boolean contiguous-p)
! (type t result-type));; CL type
(declare-values (sequence pixel) (sequence mask))
(let ((display (colormap-display colormap))
pixel-sequence mask-sequence)
***************
*** 1095,1107 ****
((data boolean) contiguous-p)
(colormap colormap)
(card16 colors planes))
! (with-buffer-reply (display nil :sizes 16)
! (let ((npixels (card16-get 8))
! (nmasks (card16-get 10)))
! (setq pixel-sequence
! (sequence-get :result-type result-type :length npixels))
! (setq mask-sequence
! (sequence-get :result-type result-type :length nmasks)))))
(display-invoke-after-function display)
(values pixel-sequence mask-sequence)))
--- 1095,1108 ----
((data boolean) contiguous-p)
(colormap colormap)
(card16 colors planes))
! (with-input-lock (display)
! (with-buffer-reply (display nil :sizes 16)
! (let ((npixels (card16-get 8))
! (nmasks (card16-get 10)))
! (setq pixel-sequence
! (sequence-get :result-type result-type :length npixels))
! (setq mask-sequence
! (sequence-get :result-type result-type :length nmasks))))))
(display-invoke-after-function display)
(values pixel-sequence mask-sequence)))
***************
*** 1202,1220 ****
(let ((display (colormap-display colormap))
sequence)
(with-display (display)
! (with-buffer-request (display *x-querycolors* :no-after)
! (colormap colormap)
! (sequence pixels))
! (wait-for-reply display nil)
! (reading-buffer-reply (display :sizes (8 16))
! (let* ((ncolors (card16-get 8)))
! (setq sequence (make-sequence result-type ncolors))
! (dotimes (i ncolors sequence)
! (buffer-input display buffer-bbuf 0 8)
! (setf (elt sequence i)
! (make-color :red (rgb-val-get 0)
! :green (rgb-val-get 2)
! :blue (rgb-val-get 4)))))))
(display-invoke-after-function display)
sequence))
--- 1203,1222 ----
(let ((display (colormap-display colormap))
sequence)
(with-display (display)
! (with-input-lock (display)
! (with-buffer-request (display *x-querycolors* :no-after)
! (colormap colormap)
! (sequence pixels))
! (wait-for-reply display nil)
! (reading-buffer-reply (display :sizes (8 16))
! (let* ((ncolors (card16-get 8)))
! (setq sequence (make-sequence result-type ncolors))
! (dotimes (i ncolors sequence)
! (buffer-input display buffer-bbuf 0 8)
! (setf (elt sequence i)
! (make-color :red (rgb-val-get 0)
! :green (rgb-val-get 2)
! :blue (rgb-val-get 4))))))))
(display-invoke-after-function display)
sequence))
∂18-Apr-89 0437 CL-Windows-mailer LISZT Programming
Received: from oberon.usc.edu by SAIL.Stanford.EDU with TCP; 18 Apr 89 04:37:02 PDT
Received: from loki.usc.edu by oberon.usc.edu (5.59/5.5) id AA07841;
Tue, 18 Apr 89 04:36:30 PST
Received: by loki.usc.edu (3.2/SMI-3.0DEV3) id AA15367;
Tue, 18 Apr 89 04:36:33 PDT
Date: Tue, 18 Apr 89 04:36:33 PDT
From: temin%loki.usc.edu@oberon.usc.edu (Aaron Temin)
Message-Id: <8904181136.AA15367@loki.usc.edu>
To: cl-windows@sail.stanford.edu
Subject: LISZT Programming
I don't think Liszt (Express Windows) is on the net,
but their mailing address is :
Liszt Programming, Inc.
P.O. Box 15447
Arlington, VA 22215
Phone: 703-683-3916.
ILA (International LISP Associates) is in Cambridge, MA but I don't
have an address.
-Aaron
∂18-Apr-89 2300 CL-Windows-mailer LISZT Programming
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 18 Apr 89 23:00:16 PDT
Received: from KANGCHENJUNGA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Tue 18 Apr 89 10:10:36-CDT
Date: Tue, 18 Apr 89 10:11 CDT
From: William D. Gooch <ai.gooch@MCC.COM>
Subject: LISZT Programming
To: temin%loki.usc.edu@oberon.usc.edu
cc: cl-windows@sail.stanford.edu
In-Reply-To: <8904181136.AA15367@loki.usc.edu>
Message-ID: <19890418151110.7.GOOCH@KANGCHENJUNGA.ACA.MCC.COM>
ILA (International LISP Associates) is in Cambridge, MA but I don't
have an address.
Their number in Palo Alto is (415) 968-3656. (They have folks there too.)
∂19-Apr-89 0549 CL-Windows-mailer Event processing with Timeout 0
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Apr 89 05:49:48 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08790; Wed, 19 Apr 89 05:50:45 PDT
Date: Wed, 19 Apr 89 05:50:45 PDT
Message-Id: <8904191250.AA08790@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-windows@sail.stanford.edu; id AA08790; Wed, 19 Apr 89 05:50:45 PDT
From: lowry%aitg.DEC@decwrl.dec.com (David Lowry, VAX LISP 291-8070)
To: cl-windows@sail.stanford.edu
Subject: Event processing with Timeout 0
I'm confused about what the correct behavior is when :timeout is 0 in
calls to EVENT-CASE, PROCESS-EVENT and EVENT-COND.
My guess is it does the following:
Check all the events in the event queue, and unless one of the clauses
or handlers returns non-nil, returns nil. If discard-p is true, the
events that returned NIL are discarded. Thus if timeout is 0 and
discard-p is true and no events return non-NIL, the queue will be empty
afterwards.
I'm guessing this from the behavior of EVENT-LISTEN, and there does not
appear to be a way to clear unwanted events out of the queue and then
return immediately. So do I win the stuffed animal or go to the end of
the line?
D. Lowry
DEC
∂20-Apr-89 0731 CL-Windows-mailer Event processing with Timeout 0
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:30:57 PDT
Received: by ti.com id AA05693; Wed, 19 Apr 89 19:47:19 CDT
Received: from stroke.csc.ti.com by tilde id AA27931; Thu, 20 Apr 89 09:06:17 CDT
Received: by stroke.csc.ti.com (4.0/SMI-4.0)
id AA04375; Thu, 20 Apr 89 09:06:12 CDT
Date: Thu, 20 Apr 89 09:06:12 CDT
From: oren@stroke.csc.ti.com (LaMott Oren)
Message-Id: <8904201406.AA04375@stroke.csc.ti.com>
To: lowry%aitg.DEC@decwrl.dec.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: David Lowry, VAX LISP 291-8070's message of Wed, 19 Apr 89 05:50:45 PDT <8904191250.AA08790@decwrl.dec.com>
Subject: Event processing with Timeout 0
You win the stuffed animal.
Just to make sure you're not confused about the peek-p parameter: When peek-p
is NIL (the default) the events for clauses that return non-nil are discarded.
So when discard-p is T and peek-p is NIL the events for all matching clauses
are removed from the queue, regardless of their return value.
∂20-Apr-89 0809 CL-Windows-mailer Event processing with Timeout 0
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:30:57 PDT
Received: by ti.com id AA05693; Wed, 19 Apr 89 19:47:19 CDT
Received: from stroke.csc.ti.com by tilde id AA27931; Thu, 20 Apr 89 09:06:17 CDT
Received: by stroke.csc.ti.com (4.0/SMI-4.0)
id AA04375; Thu, 20 Apr 89 09:06:12 CDT
Date: Thu, 20 Apr 89 09:06:12 CDT
From: oren@stroke.csc.ti.com (LaMott Oren)
Message-Id: <8904201406.AA04375@stroke.csc.ti.com>
To: lowry%aitg.DEC@decwrl.dec.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: David Lowry, VAX LISP 291-8070's message of Wed, 19 Apr 89 05:50:45 PDT <8904191250.AA08790@decwrl.dec.com>
Subject: Event processing with Timeout 0
You win the stuffed animal.
Just to make sure you're not confused about the peek-p parameter: When peek-p
is NIL (the default) the events for clauses that return non-nil are discarded.
So when discard-p is T and peek-p is NIL the events for all matching clauses
are removed from the queue, regardless of their return value.
∂25-Apr-89 1310 CL-Windows-mailer Xlib ==> CLX concordance?
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 25 Apr 89 13:10:36 PDT
Received: from vax9.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA04601; Tue, 25 Apr 89 16:15:10 edt
Message-Id: <8904252015.AA04601@crash.cs.umass.edu>
Date: Tue, 25 Apr 89 16:12 EST
From: BROLIO@cs.umass.EDU
Subject: Xlib ==> CLX concordance?
To: cl-windows@sail.stanford.EDU
X-Vms-To: LISPX
Has anyone made a concordance of the c Xlib to Lisp CLX?
The question is, given an Xlib procedure in C, what
CLX procedure in Lisp corresponds to it? For example,
I figured out, after some head scratching that
CreatePixmapFromBitmapData and some other functions
were implemented by xlib:create-image. Such a concordance
would be pretty useful, since one could then use the
O'Reilly X books as an intro to CLX and even as much-
needed documentation. Let me know soon if someone has
one -- I am starting work on it and don't want to RITW.
John Brolio
GBB Development Group
brolio@cs.umass.edu
∂25-Apr-89 1317 CL-Windows-mailer Xlib ==> CLX concordance?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 13:16:55 PDT
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA00383g; Tue, 25 Apr 89 13:15:17 PDT
Received: by boston-harbor id AA06928g; Tue, 25 Apr 89 16:17:21 EDT
Date: Tue, 25 Apr 89 16:17:21 EDT
From: Judy Anderson <yduJ@lucid.com>
Message-Id: <8904252017.AA06928@boston-harbor>
To: BROLIO@cs.umass.EDU
Cc: cl-windows@sail.stanford.EDU
In-Reply-To: BROLIO@cs.umass.EDU's message of Tue, 25 Apr 89 16:12 EST <8904252015.AA04601@crash.cs.umass.edu>
Subject: Xlib ==> CLX concordance?
In the clx file doc.l there's a concordance of CLX to X Protocol
requests. If you had a concordance of Xlib to X Protocol then you
could combine the two... This wouldn't be perfect of course, but it
could be helpful.
yduJ (Judy Anderson)
Lucid East
yduJ@lucid.com
edsel!yduJ@labrea.stanford.edu
...!sun!edsel!yduJ
(617)784-6114
∂02-May-89 1534 CL-Windows-mailer Re: improved version of CLX available
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 May 89 15:34:13 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA18128; Tue, 2 May 89 15:22:44 -0700
Received: by franz (MC 2.0/3.14)
id AA04880; Tue, 2 May 89 14:53:14 PDT
Received: by sparky (4.0/3.14)
id AA18661; Tue, 2 May 89 14:55:30 PDT
Return-Path: <sparky!jdi>
Message-Id: <8905022155.AA18661@sparky>
To: franz!zermatt.lcs.mit.edu!bug-clx, franz!sail.stanford.edu!cl-windows
Cc: franz!expo.lcs.mit.edu!xpert
Subject: Re: improved version of CLX available
Date: Tue, 02 May 89 14:55:28 -0700
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
A new revision of the improved CLX first announced March 30 is available via
public ftp on:
ucbarpa (10.0.0.78, 128.32.130.11) in ~ftp/pub/clx.tar.Z
Below is the list of changes from the March 30 version. (The big one is
support for Lucid version 3.0) This revision missed by a day but I'll call
it May Day CLX anyway. Once again, this CLX is completely compatible with
the CLX on the X11.R3 tape, minus some of the bugs and some of the slowness.
John Irwin, jdi%franz.uucp@uunet.uu.net, uunet!franz!jdi
General changes
---------------
Stan Lanning's fix to event-case when discard-p is t, peek-p is nil.
-- input.l
Kerry Kimbrough's new version of get-search-table, fixes resource
name handling.
-- resource.l
Lisp implementation specific changes
------------------------------------
-- fix to exclMakefile to reduce space used by CLX image
-- Judy Anderson's fixes for Lucid 3.0 -- better I/O and locking
-- dependent.l
∂02-May-89 1922 CL-Windows-mailer CLUE/CLX
Received: from helios.northeastern.edu by SAIL.Stanford.EDU with TCP; 2 May 89 19:22:05 PDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa15537; 2 May 89 22:21 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
id AA21728; Tue, 2 May 89 22:19:03 ADT
Received: by eric.CCS.Northeastern.EDU (3.2/SMI-3.2+CCS-subsidiary-2.2)
id AA15236; Tue, 2 May 89 22:18:04 EDT
Date: Tue, 2 May 89 22:18:04 EDT
From: Paul Steckler <steck@eric.ccs.northeastern.edu>
Message-Id: <8905030218.AA15236@eric.CCS.Northeastern.EDU>
To: cl-windows@sail.stanford.edu
Subject: CLUE/CLX
Cc: clue-review@dsg.csc.ti.com, futrell@corwin.ccs.northeastern.edu,
steck@eric
At Northeastern University in Boston, we are developing Lisp-based
software on a stock Symbolics 3600 running Genera 7.2, and
on MacIvory machines running Genera 7.4. We are interested in
using CLUE/CLX for interface development.
Can you briefly indicate what software we'll need to make this go?
Are CLUE/CLX compatible with X11 R.3?
Thanks for your attention.
Paul Steckler
∂03-May-89 0925 CL-Windows-mailer Re: CLUE/CLX
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 May 89 09:25:42 PDT
Received: by ti.com id AA01493; Wed, 3 May 89 11:24:09 CDT
Received: from dsg by tilde id AA01266; Wed, 3 May 89 11:02:28 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 3 May 89 09:50:33 CDT
Message-Id: <2819199128-15978920@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 3 May 89 09:52:08 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Paul Steckler <steck@eric.ccs.northeastern.edu>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLUE/CLX
In-Reply-To: Msg of Tue, 2 May 89 22:18:04 EDT from Paul Steckler <steck@eric.ccs.northeastern.edu>
> At Northeastern University in Boston, we are developing Lisp-based
> software on a stock Symbolics 3600 running Genera 7.2, and
> on MacIvory machines running Genera 7.4. We are interested in
> using CLUE/CLX for interface development.
>
> Can you briefly indicate what software we'll need to make this go?
> Are CLUE/CLX compatible with X11 R.3?
Yes. In fact, you'll find the most recently-released versions of both CLX and
CLUE in the R3 distribution. See lib/CLX and contrib/toolkits/clue. Both of
these systems are portable Common Lisp which should run under Genera right out
of the box, with little or no modification.
You will need CLOS to make CLUE work. For many, this means getting PCL from
Gregor Kiczales at Xerox PARC. Ftp from arisia.xerox.com in the /pcl directory
or inquire at CommonLoops.pa@xerox.com. Alternatively, you can use CLOS-KLUDGE.
This is a simple implementation of a CLOS subset that comes with CLUE. It is
sufficient for getting started with CLUE programming, but not for truly
interesting development.
∂24-May-89 0817 CL-Windows-mailer Y windows
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 24 May 89 08:17:02 PDT
Return-Path: <singer@Think.COM>
Received: from kulla.think.com by Think.COM; Wed, 24 May 89 10:51:35 EDT
Received: by kulla.think.com; Wed, 24 May 89 10:51:10 EDT
Date: Wed, 24 May 89 10:51:10 EDT
From: singer@Think.COM
Message-Id: <8905241451.AA27349@kulla.think.com>
To: cl-windows@sail.stanford.edu
Subject: Y windows
Would anyone care to make a few general comments on Y windows?
Alexander Singer
Thinkning Machines Corp.
singer@think.com
∂05-Jun-89 0351 CL-Windows-mailer CLUE for Lucid?
Received: from usc.edu by SAIL.Stanford.EDU with TCP; 5 Jun 89 03:51:30 PDT
Received: from loki.usc.edu by usc.edu (5.59/SMI-3.0DEV3) id AA18848;
Mon, 5 Jun 89 03:51:38 PDT
Received: by loki.usc.edu (4.0/SMI-3.0DEV3) id AA08619;
Mon, 5 Jun 89 03:51:32 PDT
Date: Mon, 5 Jun 89 03:51:32 PDT
From: temin%loki.usc.edu@usc.edu (Aaron Temin)
Message-Id: <8906051051.AA08619@loki.usc.edu>
To: clue-review@dsg.csc.ti.com
Subject: CLUE for Lucid?
Cc: cl-windows@sail.stanford.edu, temin@loki.usc.edu
Are there patches around to adapt CLUE to Lucid CL? (Or any patches
in general?) I have the version from the R3 tape and the README
says its been tested on TI, Symbolics and Franz Allegro.
Many thanks,
Aaron Temin
temin%loki.usc.edu@oberon.usc.edu
∂07-Jun-89 0657 CL-Windows-mailer CLUE for Lucid?
Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 7 Jun 89 06:57:50 PDT
Return-Path: <elaine@starbase.mitre.org>
Received: by gateway.mitre.org (5.54/SMI-2.2)
id AA05885; Wed, 7 Jun 89 09:58:29 EDT
Received: by starbase (4.0/SMI-4.0)
id AA07283; Wed, 7 Jun 89 09:57:31 EDT
Date: Wed, 7 Jun 89 09:57:31 EDT
From: elaine@starbase.mitre.org (Elaine Lusher)
Message-Id: <8906071357.AA07283@starbase>
To: temin%loki.usc.edu@usc.edu
Cc: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
temin@loki.usc.edu
In-Reply-To: Aaron Temin's message of Mon, 5 Jun 89 03:51:32 PDT <8906051051.AA08619@loki.usc.edu>
Subject: CLUE for Lucid?
Aaron,
My information is a little old since I haven't followed CLUE for several
months. However, I talked to someone at MIT named Ian Hopswill who
apparently has gotten CLUE running under Lucid 3.0 and has a patch file
(CLUE needs to be integrated with Lucid's I/O system). His net address is
idh@ai.ai.mit.edu. Please let me know if you get the code - I would also
like a copy. Hope this helps. Feel free to contact me if you need further
info.
Elaine Lusher
Mitre Corp.
∂09-Jun-89 0700 CL-Windows-mailer CLX speed
Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 9 Jun 89 07:00:18 PDT
Received: from think.UUCP by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP
id AA29449; Fri, 9 Jun 89 10:00:33 EDT
From: singer@news.think.com
Received: from kulla.think.com by news.think.com; Fri, 9 Jun 89 10:00:02 EDT
Received: by kulla.think.com; Fri, 9 Jun 89 09:58:35 EDT
Date: Fri, 9 Jun 89 09:58:35 EDT
Message-Id: <8906091358.AA00416@kulla.think.com>
To: cl-windows@sail.stanford.edu
Cc: singer@news.think.com
Subject: CLX speed
What is the general difference in speed between CLX and raw X, i.e.
how much does it cost me to be using LISP? Would I,
exclusively in terms of speed and without considering all the advantages of
LISP over C, gain anything by writing a graphics interface in C and then
writing an additional interface between my application and the interface,
thereby reducing the number of foreign function calls to only those between
my applicationa and its user interface?
Alex Singer
Thinking Machines Corp.
245 First St.
Cambridge, MA 02142
∂09-Jun-89 0927 CL-Windows-mailer Re: CLX speed
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 9 Jun 89 09:27:07 PDT
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by Think.COM; Fri, 9 Jun 89 12:27:26 EDT
Received: from localhost by prometheus.think.com; Fri, 9 Jun 89 12:26:11 EDT
Message-Id: <8906091626.AA20634@prometheus.think.com>
To: singer@Think.COM
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX speed
In-Reply-To: Your message of Fri, 09 Jun 89 09:58:35 -0400.
<8906091358.AA00416@kulla.think.com>
Date: Fri, 09 Jun 89 12:26:09 EDT
From: Gary Oberbrunner <garyo@Think.COM>
Alex writes:
What is the general difference in speed between CLX and raw X, i.e.
how much does it cost me to be using LISP?
Alex Singer
Thinking Machines Corp.
245 First St.
Cambridge, MA 02142
I assume you're talking here of an application that spends most of its
time rendering and little of it computing. In this graphics-limited case,
the two languages will be the same, because the protocol pipeline will be
full, and the server (in your case a Sun, right?) will be running flat-out
drawing our graphics.
You *will* see a speed difference when the pipeline empties and you need
to refill it, or when you do anything interactive (like handling events).
Events flush the pipe, so the language speed comes into play in turning
around the event and generating more graphics requests.
However, even here, the Ethernet time will probably swamp the compute (i.e.
language-specific) time.
Hope this helps.
As always,
Gary Oberbrunner
Thinking Machines Corp.
245 First St.
Cambridge, MA 02142
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265
∂09-Jun-89 1314 CL-Windows-mailer Re: CLX speed
Received: from uunet.uu.net ([192.48.96.2]) by SAIL.Stanford.EDU with TCP; 9 Jun 89 13:14:52 PDT
Received: from franz.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA10640; Fri, 9 Jun 89 16:15:10 -0400
Received: by franz.franz.uucp (MC 2.0/FI-0.97)
id AA09792; Fri, 9 Jun 89 13:12:23 PDT
Received: by sparky.franz.uucp (4.0/FI-0.97)
id AA10718; Fri, 9 Jun 89 13:08:12 PDT
Message-Id: <8906092008.AA10718@sparky.franz.uucp>
To: singer@news.think.com
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX speed
In-Reply-To: Your message of Fri, 09 Jun 89 09:58:35 -0400.
<8906091358.AA00416@kulla.think.com>
Date: Fri, 09 Jun 89 13:08:10 -0700
From: John Irwin <franz!jdi@uunet.UU.NET>
Your message:
What is the general difference in speed between CLX and raw X, i.e.
how much does it cost me to be using LISP? Would I,
exclusively in terms of speed and without considering all the advantages of
LISP over C, gain anything by writing a graphics interface in C and then
writing an additional interface between my application and the interface,
thereby reducing the number of foreign function calls to only those between
my applicationa and its user interface?
--------
Well, CLX doesn't really need to do foreign function calls at all. Some
implementations do because it's quicker or easier that way. But, in essence,
CLX speaks directly over a socket to the X server without going through C.
CLX code isn't too hard to translate into Xlib, and vice versa. My suggestion
is to try writing your graphics interface in CLX, and then translating it to C
later if you need additional performance.
You'll almost certainly be able to develop the code faster in Lisp than you
would using Xlib.
-- John Irwin, jdi@franz.com
∂11-Jun-89 2010 CL-Windows-mailer CLX programming..
Received: from columbia.edu by SAIL.Stanford.EDU with TCP; 11 Jun 89 20:10:25 PDT
Received: from gollum.cs.columbia.edu by columbia.edu (5.59++/0.3) with SMTP
id AA27031; Sun, 11 Jun 89 23:10:39 EDT
Message-Id: <8906120310.AA27031@columbia.edu>
Received: by gollum.cs.columbia.edu (5.54/5.10) id AA05039; Sun, 11 Jun 89 23:10:34 EDT
Date: Sun, 11 Jun 89 23:10:34 EDT
From: Ari Shamash <shamash@gollum.cs.columbia.edu>
To: cl-windows@sail.stanford.edu
Subject: CLX programming..
Hi there,
I am trying to learn how to use CLX. Although the documentation
available from T.I. is a great start (a great many thanks to whomever
made it available), it is not really enough. Does somebody have a
rather large program (written in CLX) that I can possibly look at?
Any leads would be appreciated.
Also, does somebody have simple pop-up menu routines I can use? I am
not looking for an extensive toolkit, just some simple pop-up menus.
Thanks in advance,
Ari
(shamash@gollum.cs.columbia.edu)
∂12-Jun-89 0636 CL-Windows-mailer Re: CLX programming..
Received: from CHILES.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Jun 89 06:35:40 PDT
Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 12 Jun 89 09:34:25 EDT
To: Ari Shamash <shamash@gollum.cs.columbia.edu>
cc: cl-windows@sail.stanford.edu
Subject: Re: CLX programming..
In-reply-to: Your message of Sun, 11 Jun 89 23:10:34 -0400.
<8906120310.AA27031@columbia.edu>
Date: Mon, 12 Jun 89 09:34:04 EDT
Message-ID: <14675.613661644@CHILES.SLISP.CS.CMU.EDU>
From: Bill.Chiles@WB1.CS.CMU.EDU
Here's some demo hacks we whipped up, nothing too great.
Have fun,
Bill
*******************************************************************************
;;; -*- Mode: Lisp; Package: Demos -*-
;;;
;;; **********************************************************************
;;; This code was written as part of the CMU Common Lisp project at
;;; Carnegie-Mellon University, and has been placed in the public domain.
;;; CMU Common Lisp is currently incomplete and under active development.
;;; If you want to use this code or any part of CMU Common Lisp, please
;;; contact Scott Fahlman (FAHLMAN@CMUC).
;;; **********************************************************************
;;;
;;; This file contains various graphics hacks written and ported over the
;;; years by various and numerous persons.
;;;
;;; This file should be portable to any valid Common Lisp with CLX -- DEC 88.
;;;
(in-package "DEMOS" :use '("LISP"))
(export '(do-all-demos demo))
!
;;;; Graphic demos wrapper macro.
;;; This wrapper macro should be reconsidered with respect to its property
;;; list usage. Possibly a demo structure should be used with *demos*
;;; pointing to these instead of function names. Also, something should
;;; be done about a title window that displays the name of the demo while
;;; it is running.
(defparameter *demos* nil)
(defvar *display* nil)
(defvar *screen* nil)
(defvar *root* nil)
(defvar *black-pixel* nil)
(defvar *white-pixel* nil)
(defvar *window* nil)
(defmacro defdemo (fun-name demo-name args x y width height doc &rest forms)
`(progn
(defun ,fun-name ,args
,doc
(cond (*display*
(xlib:with-state (*window*)
(setf (xlib:drawable-x *window*) ,x)
(setf (xlib:drawable-y *window*) ,y)
(setf (xlib:drawable-width *window*) ,width)
(setf (xlib:drawable-height *window*) ,height)))
(t
#+:cmu
(multiple-value-setq (*display* *screen*) (ext:open-clx-display))
#-:cmu
(progn
;; Portable method
(setf *display* (xlib:open-display (machine-instance)))
(setf *screen* (xlib:display-default-screen *display*)))
(setf *root* (xlib:screen-root *screen*))
(setf *black-pixel* (xlib:screen-black-pixel *screen*))
(setf *white-pixel* (xlib:screen-white-pixel *screen*))
(setf *window* (xlib:create-window :parent *root*
:x ,x :y ,y
:event-mask nil
:width ,width :height ,height
:background *white-pixel*
:border *black-pixel*
:border-width 2
:override-redirect :on))))
(xlib:map-window *window*)
;;
;; I hate to do this since this is not something any normal
;; program should do ...
(setf (xlib:window-priority *window*) :above)
(xlib:display-finish-output *display*)
(unwind-protect
(progn ,@forms)
(xlib:unmap-window *window*)
(xlib:display-finish-output *display*)))
(setf (get ',fun-name 'demo-name) ',demo-name)
(setf (get ',fun-name 'demo-doc) ',doc)
(export ',fun-name)
(pushnew ',fun-name *demos*)
',fun-name))
!
;;;; Main entry points.
(defun do-all-demos ()
(dolist (demo *demos*)
(funcall demo)
(sleep 3)))
;;; DEMO is a hack to get by. It should be based on creating a menu. At
;;; that time, *name-to-function* should be deleted, since this mapping will
;;; be manifested in the menu slot name cross its action. Also the
;;; "Shove-bounce" demo should be renamed to "Shove bounce"; likewise for
;;; "Fast-towers-of-Hanoi" and "Slow-towers-of-hanoi".
;;;
(defvar *name-to-function* (make-hash-table :test #'eq))
(defvar *keyword-package* (find-package "KEYWORD"))
(defun demo ()
(macrolet ((read-demo ()
`(let ((*package* *keyword-package*))
(read))))
(dolist (d *demos*)
(setf (gethash (intern (string-upcase (get d 'demo-name))
*keyword-package*)
*name-to-function*)
d))
(loop
(fresh-line)
(dolist (d *demos*)
(write-string " ")
(write-line (get d 'demo-name)))
(write-string " ")
(write-line "Help <demo name>")
(write-string " ")
(write-line "Quit")
(write-string "Enter demo name: ")
(let ((demo (read-demo)))
(case demo
(:help
(let* ((demo (read-demo))
(fun (gethash demo *name-to-function*)))
(fresh-line)
(if fun
(format t "~&~%~A~&~%" (get fun 'demo-doc))
(format t "Unknown demo name -- ~A." demo))))
(:quit (return t))
(t
(let ((fun (gethash demo *name-to-function*)))
(if fun
(funcall fun)
(format t "~&~%Unknown demo name -- ~A.~&~%" demo)))))))))
!
;;;; Shared demo utilities.
(defun full-window-state (w)
(xlib:with-state (w)
(values (xlib:drawable-width w) (xlib:drawable-height w)
(xlib:drawable-x w) (xlib:drawable-y w)
(xlib:window-map-state w))))
!
;;;; Greynetic.
;;; GREYNETIC displays random sized and shaded boxes in a window. This is
;;; real slow. It needs work.
;;;
(defun greynetic (window duration)
(let* ((pixmap (xlib:create-pixmap :width 32 :height 32 :depth 1
:drawable window))
(gcontext (xlib:create-gcontext :drawable window
:background *white-pixel*
:foreground *black-pixel*
:tile pixmap
:fill-style :tiled)))
(multiple-value-bind (width height) (full-window-state window)
(dotimes (i duration)
(let* ((pixmap-data (greynetic-pixmapper))
(image (xlib:create-image :width 32 :height 32
:depth 1 :data pixmap-data)))
(xlib:put-image pixmap gcontext image :x 0 :y 0 :width 32 :height 32)
(xlib:draw-rectangle window gcontext
(- (random width) 5)
(- (random height) 5)
(+ 4 (random (truncate width 3)))
(+ 4 (random (truncate height 3)))
t))
(xlib:display-force-output *display*)))
(xlib:free-gcontext gcontext)
(xlib:free-pixmap pixmap)))
(defvar *greynetic-pixmap-array*
(make-array '(32 32) :initial-element 0 :element-type 'xlib:pixel))
(defun greynetic-pixmapper ()
(let ((pixmap-data *greynetic-pixmap-array*))
(dotimes (i 4)
(declare (fixnum i))
(let ((nibble (random 16)))
(setf nibble (logior nibble (ash nibble 4))
nibble (logior nibble (ash nibble 8))
nibble (logior nibble (ash nibble 12))
nibble (logior nibble (ash nibble 16)))
(dotimes (j 32)
(let ((bit (if (logbitp j nibble) 1 0)))
(setf (aref pixmap-data i j) bit
(aref pixmap-data (+ 4 i) j) bit
(aref pixmap-data (+ 8 i) j) bit
(aref pixmap-data (+ 12 i) j) bit
(aref pixmap-data (+ 16 i) j) bit
(aref pixmap-data (+ 20 i) j) bit
(aref pixmap-data (+ 24 i) j) bit
(aref pixmap-data (+ 28 i) j) bit)))))
pixmap-data))
(defdemo greynetic-demo "Greynetic" (&optional (duration 300))
100 100 600 600
"Displays random grey rectangles."
(greynetic *window* duration))
!
;;;; Qix.
(defstruct qix
buffer
(dx1 5)
(dy1 10)
(dx2 10)
(dy2 5))
(defun construct-qix (length)
(let ((qix (make-qix)))
(setf (qix-buffer qix) (make-circular-list length))
qix))
(defun make-circular-list (length)
(let ((l (make-list length)))
(rplacd (last l) l)))
(defun qix (window lengths duration)
"Each length is the number of lines to put in a qix, and that many qix
(of the correct size) are put up on the screen. Lets the qix wander around
the screen for Duration steps."
(let ((histories (mapcar #'construct-qix lengths)))
(multiple-value-bind (width height) (full-window-state window)
(declare (fixnum width height))
(xlib:clear-area window)
(xlib:display-force-output *display*)
(do ((h histories (cdr h))
(l lengths (cdr l)))
((null h))
(do ((x (qix-buffer (car h)) (cdr x))
(i 0 (1+ i)))
((= i (car l)))
(rplaca x (make-array 4))))
;; Start each qix at a random spot on the screen.
(dolist (h histories)
(let ((x (random width))
(y (random height)))
(rplaca (qix-buffer h)
(make-array 4 :initial-contents (list x y x y)))))
(rplacd (last histories) histories)
(let (x1 y1 x2 y2 dx1 dy1 dx2 dy2 tem line next-line qix
(gc (xlib:create-gcontext :drawable window
:foreground *white-pixel*
:background *black-pixel*
:line-width 0 :line-style :solid
:function boole-c2)))
(declare (fixnum x1 y1 x2 y2 dx1 dy1 dx2 dy2))
(dotimes (i duration)
;; Line is the next line in the next qix. Rotate this qix and
;; the qix ring.
(setq qix (car histories))
(setq line (car (qix-buffer qix)))
(setq next-line (cadr (qix-buffer qix)))
(setf (qix-buffer qix) (cdr (qix-buffer qix)))
(setq histories (cdr histories))
(setf x1 (svref line 0))
(setf y1 (svref line 1))
(setf x2 (svref line 2))
(setf y2 (svref line 3))
(xlib:draw-line window gc x1 y1 x2 y2)
(setq dx1 (- (+ (qix-dx1 qix) (random 3)) 1))
(setq dy1 (- (+ (qix-dy1 qix) (random 3)) 1))
(setq dx2 (- (+ (qix-dx2 qix) (random 3)) 1))
(setq dy2 (- (+ (qix-dy2 qix) (random 3)) 1))
(cond ((> dx1 10) (setq dx1 10))
((< dx1 -10) (setq dx1 -10)))
(cond ((> dy1 10) (setq dy1 10))
((< dy1 -10) (setq dy1 -10)))
(cond ((> dx2 10) (setq dx2 10))
((< dx2 -10) (setq dx2 -10)))
(cond ((> dy2 10) (setq dy2 10))
((< dy2 -10) (setq dy2 -10)))
(cond ((or (>= (setq tem (+ x1 dx1)) width) (minusp tem))
(setq dx1 (- dx1))))
(cond ((or (>= (setq tem (+ x2 dx2)) width) (minusp tem))
(setq dx2 (- dx2))))
(cond ((or (>= (setq tem (+ y1 dy1)) height) (minusp tem))
(setq dy1 (- dy1))))
(cond ((or (>= (setq tem (+ y2 dy2)) height) (minusp tem))
(setq dy2 (- dy2))))
(setf (qix-dy2 qix) dy2)
(setf (qix-dx2 qix) dx2)
(setf (qix-dy1 qix) dy1)
(setf (qix-dx1 qix) dx1)
(when (svref next-line 0)
(xlib:draw-line window gc
(svref next-line 0) (svref next-line 1)
(svref next-line 2) (svref next-line 3)))
(setf (svref next-line 0) (+ x1 dx1))
(setf (svref next-line 1) (+ y1 dy1))
(setf (svref next-line 2) (+ x2 dx2))
(setf (svref next-line 3) (+ y2 dy2))
(xlib:display-force-output *display*))))))
(defdemo qix-demo "Qix" (&optional (lengths '(30 30)) (duration 2000))
0 0 700 700
"Hypnotic wandering lines."
(qix *window* lengths duration))
!
;;;; Petal.
;;; Fast sine constants:
(defconstant d360 #o5500)
(defconstant d270 #o4160)
(defconstant d180 #o2640)
(defconstant d90 #o1320)
(defconstant vecmax 2880)
(defconstant sin-array
'#(#o0 #o435 #o1073 #o1531 #o2166 #o2623 #o3260
#o3714 #o4350 #o5003 #o5435 #o6066 #o6516 #o7145
#o7573 #o10220 #o10644 #o11266 #o11706 #o12326
#o12743 #o13357 #o13771 #o14401 #o15007 #o15414
#o16016 #o16416 #o17013 #o17407 #o20000 #o20366
#o20752 #o21333 #o21711 #o22265 #o22636 #o23204
#o23546 #o24106 #o24443 #o24774 #o25323 #o25645
#o26165 #o26501 #o27011 #o27316 #o27617 #o30115
#o30406 #o30674 #o31156 #o31434 #o31706 #o32154
#o32416 #o32654 #o33106 #o33333 #o33554 #o33771
#o34202 #o34406 #o34605 #o35000 #o35167 #o35351
#o35526 #o35677 #o36043 #o36203 #o36336 #o36464
#o36605 #o36721 #o37031 #o37134 #o37231 #o37322
#o37407 #o37466 #o37540 #o37605 #o37646 #o37701
#o37730 #o37751 #o37766 #o37775 #o40000))
(defmacro psin (val)
`(let* ((val ,val)
neg
frac
sinlo)
(if (>= val d180)
(setq neg t
val (- val d180)))
(if (>= val d90)
(setq val (- d180 val)))
(setq frac (logand val 7))
(setq val (ash val -3))
;;
(setq sinlo (if (>= val 90)
(svref sin-array 90)
(svref sin-array val)))
;;
(if (< val 90)
(setq sinlo
(+ sinlo (ash (* frac (- (svref sin-array (1+ val)) sinlo))
-3))))
;;
(if neg
(- sinlo)
sinlo)))
(defmacro pcos (x)
`(let ((tmp (- ,x d270)))
(psin (if (minusp tmp) (+ tmp d360) tmp))))
!
;;;; Miscellaneous petal hackery.
(defmacro high-16bits-* (a b)
`(let ((a-h (ash ,a -8))
(b-h (ash ,b -8)))
(+ (* a-h b-h)
(ash (* a-h (logand ,b 255)) -8)
(ash (* b-h (logand ,a 255)) -8))))
(defun complete (style petal)
(let ((repnum 1)
factor cntval needed)
(dotimes (i 3)
(case i
(0 (setq factor 2 cntval 6))
(1 (setq factor 3 cntval 2))
(2 (setq factor 5 cntval 1)))
(do ()
((or (minusp cntval) (not (zerop (rem style factor)))))
(setq repnum (* repnum factor))
(setq cntval (1- cntval))
(setq style (floor style factor))))
(setq needed (floor vecmax repnum))
(if (and (not (oddp needed)) (oddp petal)) (floor needed 2) needed)))
!
;;;; Petal Parameters and Petal itself
(defparameter continuous t)
(defparameter styinc 2)
(defparameter petinc 1)
(defparameter scalfac-fac 8192)
(defun petal (petal-window &optional (how-many 10) (style 0) (petal 0))
(let ((width 512)
(height 512))
(xlib:clear-area petal-window)
(xlib:display-force-output *display*)
(let ((veccnt 0)
(nustyle 722)
(nupetal 3)
(scalfac (1+ (floor scalfac-fac (min width height))))
(ctrx (floor width 2))
(ctry (floor height 2))
(tt 0)
(s 0)
(lststyle 0)
(lstpetal 0)
(petstyle 0)
(vectors 0)
(r 0)
(x1 0)
(y1 0)
(x2 0)
(y2 0)
(i 0)
(gc (xlib:create-gcontext :drawable petal-window
:foreground *black-pixel*
:background *white-pixel*
:line-width 0 :line-style :solid)))
(loop
(when (zerop veccnt)
(setq tt 0 s 0 lststyle style lstpetal petal petal nupetal
style nustyle petstyle (rem (* petal style) d360)
vectors (complete style petal))
(when continuous
(setq nupetal (+ nupetal petinc)
nustyle (+ nustyle styinc)))
(when (or (/= lststyle style) (/= lstpetal petal))
(xlib:clear-area petal-window)
(xlib:display-force-output *display*)))
(when (or (/= lststyle style) (/= lstpetal petal))
(setq veccnt (1+ veccnt) i veccnt x1 x2 y1 y2
tt (rem (+ tt style) d360)
s (rem (+ s petstyle) d360)
r (pcos s))
(setq x2 (+ ctrx (floor (high-16bits-* (pcos tt) r) scalfac))
y2 (+ ctry (floor (high-16bits-* (psin tt) r) scalfac)))
(when (/= i 1)
(xlib:draw-line petal-window gc x1 y1 x2 y2)
(xlib:display-force-output *display*)))
(when (> veccnt vectors)
(setq veccnt 0)
(setq how-many (1- how-many))
(sleep 2)
(when (zerop how-many) (return)))))))
(defdemo petal-demo "Petal" (&optional (how-many 10) (style 0) (petal 0))
100 100 512 512
"Flower-like display."
(petal *window* how-many style petal))
!
;;;; Hanoi.
;;; Random parameters:
(defparameter disk-thickness 15 "The thickness of a disk in pixels.")
(defparameter disk-spacing (+ disk-thickness 3)
"The amount of vertical space used by a disk on a needle.")
(defvar *horizontal-velocity* 20 "The speed at which disks slide sideways.")
(defvar *vertical-velocity* 12 "The speed at which disks move up and down.")
;;; These variables are bound by the main function.
(defvar *hanoi-window* () "The window that Hanoi is happening on.")
(defvar *hanoi-window-height* () "The height of the viewport Hanoi is happening on.")
(defvar *transfer-height* () "The height at which disks are transferred.")
(defvar *hanoi-gcontext* () "The graphics context for Hanoi under X11.")
;;; Needle Functions
(defstruct disk
size)
(defstruct needle
position
disk-stack)
;;; Needle-Top-Height returns the height of the top disk on NEEDLE.
(defun needle-top-height (needle)
(- *hanoi-window-height*
(* disk-spacing (length (the list (needle-disk-stack needle))))))
(defvar available-disks
(do ((i 10 (+ i 10))
(dlist () (cons (make-disk :size i) dlist)))
((> i 80) dlist)))
(defvar needle-1 (make-needle :position 184))
(defvar needle-2 (make-needle :position 382))
(defvar needle-3 (make-needle :position 584))
;;; Graphic interface abstraction:
;;; Invert-Rectangle calls the CLX function draw-rectangle with "fill-p"
;;; set to T. Update-Screen forces the display output.
;;;
(defmacro invert-rectangle (x y height width)
`(xlib:draw-rectangle *hanoi-window* *hanoi-gcontext*
,x ,y ,width ,height t))
(defmacro update-screen ()
`(xlib:display-force-output *display*))
!
;;;; Moving disks up and down
;;; Slide-Up slides the image of a disk up from the coordinates X,
;;; START-Y to the point X, END-Y. DISK-SIZE is the size of the disk to
;;; move. START-Y must be greater than END-Y
(defun slide-up (start-y end-y x disk-size)
(multiple-value-bind (number-moves pixels-left)
(truncate (- start-y end-y) *vertical-velocity*)
(do ((x (- x disk-size))
(width (* disk-size 2))
(old-y start-y (- old-y *vertical-velocity*))
(new-y (- start-y *vertical-velocity*) (- new-y *vertical-velocity*))
(number-moves number-moves (1- number-moves)))
((zerop number-moves)
(when (plusp pixels-left)
(invert-rectangle x (- old-y pixels-left) disk-thickness width)
(invert-rectangle x old-y disk-thickness width)
(update-screen)))
;; Loop body writes disk at new height & erases at old height.
(invert-rectangle x old-y disk-thickness width)
(invert-rectangle x new-y disk-thickness width)
(update-screen))))
;;; Slide-Down slides the image of a disk down from the coordinates X,
;;; START-Y to the point X, END-Y. DISK-SIZE is the size of the disk to
;;; move. START-Y must be less than END-Y.
(defun slide-down (start-y end-y x disk-size)
(multiple-value-bind (number-moves pixels-left)
(truncate (- end-y start-y) *vertical-velocity*)
(do ((x (- x disk-size))
(width (* disk-size 2))
(old-y start-y (+ old-y *vertical-velocity*))
(new-y (+ start-y *vertical-velocity*) (+ new-y *vertical-velocity*))
(number-moves number-moves (1- number-moves)))
((zerop number-moves)
(when (plusp pixels-left)
(invert-rectangle x (+ old-y pixels-left) disk-thickness width)
(invert-rectangle x old-y disk-thickness width)
(update-screen)))
;; Loop body writes disk at new height & erases at old height.
(invert-rectangle X old-y disk-thickness width)
(invert-rectangle X new-y disk-thickness width)
(update-screen))))
!
;;;; Lifting and Droping Disks
;;; Lift-disk pops the top disk off of needle and raises it up to the
;;; transfer height. The disk is returned.
(defun lift-disk (needle)
"Pops the top disk off of NEEDLE, Lifts it above the needle, & returns it."
(let* ((height (needle-top-height needle))
(disk (pop (needle-disk-stack needle))))
(slide-up height
*transfer-height*
(needle-position needle)
(disk-size disk))
disk))
;;; Drop-disk drops a disk positioned over needle at the transfer height
;;; onto needle. The disk is pushed onto needle.
(defun drop-disk (disk needle)
"DISK must be positioned above NEEDLE. It is dropped onto NEEDLE."
(push disk (needle-disk-stack needle))
(slide-down *transfer-height*
(needle-top-height needle)
(needle-position needle)
(disk-size disk))
t)
;;; Drop-initial-disk is the same as drop-disk except that the disk is
;;; drawn once before dropping.
(defun drop-initial-disk (disk needle)
"DISK must be positioned above NEEDLE. It is dropped onto NEEDLE."
(let* ((size (disk-size disk))
(lx (- (needle-position needle) size)))
(invert-rectangle lx *transfer-height* disk-thickness (* size 2))
(push disk (needle-disk-stack needle))
(slide-down *transfer-height*
(needle-top-height needle)
(needle-position needle)
(disk-size disk))
t))
!
;;;; Sliding Disks Right and Left
;;; Slide-Right slides the image of a disk located at START-X, Y to the
;;; position END-X, Y. DISK-SIZE is the size of the disk. START-X is
;;; less than END-X.
(defun slide-right (start-x end-x Y disk-size)
(multiple-value-bind (number-moves pixels-left)
(truncate (- end-x start-x) *horizontal-velocity*)
(do ((right-x (+ start-x disk-size) (+ right-x *horizontal-velocity*))
(left-x (- start-x disk-size) (+ left-x *horizontal-velocity*))
(number-moves number-moves (1- number-moves)))
((zerop number-moves)
(when (plusp pixels-left)
(invert-rectangle right-x Y disk-thickness pixels-left)
(invert-rectangle left-x Y disk-thickness pixels-left)
(update-screen)))
;; Loop body adds chunk *horizontal-velocity* pixels wide to right
;; side of disk, then chops off left side.
(invert-rectangle right-x Y disk-thickness *horizontal-velocity*)
(invert-rectangle left-x Y disk-thickness *horizontal-velocity*)
(update-screen))))
;;; Slide-Left is the same as Slide-Right except that START-X is greater
;;; than END-X.
(defun slide-left (start-x end-x Y disk-size)
(multiple-value-bind (number-moves pixels-left)
(truncate (- start-x end-x) *horizontal-velocity*)
(do ((right-x (- (+ start-x disk-size) *horizontal-velocity*)
(- right-x *horizontal-velocity*))
(left-x (- (- start-x disk-size) *horizontal-velocity*)
(- left-x *horizontal-velocity*))
(number-moves number-moves (1- number-moves)))
((zerop number-moves)
(when (plusp pixels-left)
(setq left-x (- (+ left-x *horizontal-velocity*) pixels-left))
(setq right-x (- (+ right-x *horizontal-velocity*) pixels-left))
(invert-rectangle left-x Y disk-thickness pixels-left)
(invert-rectangle right-x Y disk-thickness pixels-left)
(update-screen)))
;; Loop body adds chunk *horizontal-velocity* pixels wide to left
;; side of disk, then chops off right side.
(invert-rectangle left-x Y disk-thickness *horizontal-velocity*)
(invert-rectangle right-x Y disk-thickness *horizontal-velocity*)
(update-screen))))
!
;;;; Transferring Disks
;;; Transfer disk slides a disk at the transfer height from a position
;;; over START-NEEDLE to a position over END-NEEDLE. Modified disk is
;;; returned.
(defun transfer-disk (disk start-needle end-needle)
"Moves DISK from a position over START-NEEDLE to a position over END-NEEDLE."
(let ((start (needle-position start-needle))
(end (needle-position end-needle)))
(if (< start end)
(slide-right start end *transfer-height* (disk-size disk))
(slide-left start end *transfer-height* (disk-size disk)))
disk))
;;; Move-One-Disk moves the top disk from START-NEEDLE to END-NEEDLE.
(defun move-one-disk (start-needle end-needle)
"Moves the disk on top of START-NEEDLE to the top of END-NEEDLE."
(drop-disk (transfer-disk (lift-disk start-needle)
start-needle
end-needle)
end-needle)
t)
;;; Move-N-Disks moves the top N disks from START-NEEDLE to END-NEEDLE
;;; obeying the rules of the towers of hannoi problem. To move the
;;; disks, a third needle, TEMP-NEEDLE, is needed for temporary storage.
(defun move-n-disks (n start-needle end-needle temp-needle)
"Moves the top N disks from START-NEEDLE to END-NEEDLE.
Uses TEMP-NEEDLE for temporary storage."
(cond ((= n 1)
(move-one-disk start-needle end-needle))
(t
(move-n-disks (1- n) start-needle temp-needle end-needle)
(move-one-disk start-needle end-needle)
(move-n-disks (1- n) temp-needle end-needle start-needle)))
t)
!
;;;; Hanoi itself.
(defun hanoi (window n)
(multiple-value-bind (width height) (full-window-state window)
(declare (ignore width))
(let* ((*hanoi-window* window)
(*hanoi-window-height* height)
(*transfer-height* (- height (* disk-spacing n)))
(*hanoi-gcontext* (xlib:create-gcontext :drawable *hanoi-window*
:foreground *white-pixel*
:background *black-pixel*
:fill-style :solid
:function boole-c2)))
(xlib:clear-area *hanoi-window*)
(xlib:display-force-output *display*)
(setf (needle-disk-stack needle-1) ())
(setf (needle-disk-stack needle-2) ())
(setf (needle-disk-stack needle-3) ())
(do ((n n (1- n))
(available-disks available-disks (cdr available-disks)))
((zerop n))
(drop-initial-disk (car available-disks) needle-1))
(move-n-disks n needle-1 needle-3 needle-2)
t)))
;;; Change the names of these when the DEMO loop isn't so stupid.
;;;
(defdemo slow-hanoi-demo "Slow-towers-of-Hanoi" (&optional (how-many 4))
0 100 768 300
"Solves the Towers of Hanoi problem before your very eyes."
(let ((*horizontal-velocity* 3)
(*vertical-velocity* 1))
(hanoi *window* how-many)))
;;;
(defdemo fast-hanoi-demo "Fast-towers-of-Hanoi" (&optional (how-many 7))
0 100 768 300
"Solves the Towers of Hanoi problem before your very eyes."
(hanoi *window* how-many))
!
;;;; Bounce window.
;;; BOUNCE-WINDOW takes a window and seemingly drops it to the bottom of
;;; the screen. Optionally, the window can have an initial x velocity,
;;; screen border elasticity, and gravity value. The outer loop is
;;; entered the first time with the window at its initial height, but
;;; each iteration after this, the loop starts with the window at the
;;; bottom of the screen heading upward. The inner loop, except for the
;;; first execution, carries the window up until the negative velocity
;;; becomes positive, carrying the window down to bottom when the
;;; velocity is positive. Due to number lossage, ROUND'ing and
;;; TRUNC'ing when the velocity gets so small will cause the window to
;;; head upward with the same velocity over two iterations which will
;;; cause the window to bounce forever, so we have prev-neg-velocity and
;;; number-problems to check for this. This is not crucial with the x
;;; velocity since the loop terminates as a function of the y velocity.
;;;
(defun bounce-window (window &optional
(x-velocity 0) (elasticity 0.85) (gravity 2))
(unless (< 0 elasticity 1)
(error "Elasticity must be between 0 and 1."))
(unless (plusp gravity)
(error "Gravity must be positive."))
(multiple-value-bind (width height x y mapped) (full-window-state window)
(when (eq mapped :viewable)
(let ((top-of-window-at-bottom (- (xlib:drawable-height *root*) height))
(left-of-window-at-right (- (xlib:drawable-width *root*) width))
(y-velocity 0)
(prev-neg-velocity most-negative-fixnum)
(number-problems nil))
(declare (fixnum top-of-window-at-bottom left-of-window-at-right
y-velocity))
(loop
(when (= prev-neg-velocity 0) (return t))
(let ((negative-velocity (minusp y-velocity)))
(loop
(let ((next-y (+ y y-velocity))
(next-y-velocity (+ y-velocity gravity)))
(declare (fixnum next-y next-y-velocity))
(when (> next-y top-of-window-at-bottom)
(cond
(number-problems
(setf y-velocity (incf prev-neg-velocity)))
(t
(setq y-velocity
(- (truncate (* elasticity y-velocity))))
(when (= y-velocity prev-neg-velocity)
(incf y-velocity)
(setf number-problems t))
(setf prev-neg-velocity y-velocity)))
(setf y top-of-window-at-bottom)
(setf (xlib:drawable-x window) x
(xlib:drawable-y window) y)
(xlib:display-force-output *display*)
(return))
(setq y-velocity next-y-velocity)
(setq y next-y))
(when (and negative-velocity (>= y-velocity 0))
(setf negative-velocity nil))
(let ((next-x (+ x x-velocity)))
(declare (fixnum next-x))
(when (or (> next-x left-of-window-at-right)
(< next-x 0))
(setq x-velocity (- (truncate (* elasticity x-velocity)))))
(setq x next-x))
(setf (xlib:drawable-x window) x
(xlib:drawable-y window) y)
(xlib:display-force-output *display*))))))))
;;; Change the name of this when DEMO is not so stupid.
;;;
(defdemo shove-bounce-demo "Shove-bounce" ()
100 100 300 300
"Drops the demo window with an inital X velocity which bounces off
screen borders."
(bounce-window *window* 30))
(defdemo bounce-demo "Bounce" ()
100 100 300 300
"Drops the demo window which bounces off screen borders."
(bounce-window *window*))
!
;;;; Recurrence Demo
;;; Copyright (C) 1988 Michael O. Newton (newton@csvax.caltech.edu)
;;; Permission is granted to any individual or institution to use, copy,
;;; modify, and distribute this software, provided that this complete
;;; copyright and permission notice is maintained, intact, in all copies and
;;; supporting documentation.
;;; The author provides this software "as is" without express or
;;; implied warranty.
;;; This routine plots the recurrence
;;; x <- y(1+sin(0.7x)) - 1.2(|x|)↑.5
;;; y <- .21 - x
;;; As described in a ?? 1983 issue of the Mathematical Intelligencer
(defun recurrence (display window &optional (point-count 10000))
(let ((gc (xlib:create-gcontext :drawable window
:background *white-pixel*
:foreground *black-pixel*)))
(multiple-value-bind (width height) (full-window-state window)
(xlib:clear-area window)
(draw-ppict window gc point-count 0.0 0.0 (* width 0.5) (* height 0.5))
(xlib:display-force-output display)
(sleep 4))
(xlib:free-gcontext gc)))
;;; Draw points. X assumes points are in the range of width x height,
;;; with 0,0 being upper left and 0,H being lower left.
;;; hw and hh are half-width and half-height of screen
(defun draw-ppict (win gc count x y hw hh)
"Recursively draw pretty picture"
(unless (zerop count)
(let ((xf (floor (* (+ 1.0 x) hw ))) ;These lines center the picture
(yf (floor (* (+ 0.7 y) hh ))))
(xlib:draw-point win gc xf yf)
(draw-ppict win gc (1- count)
(- (* y (1+ (sin (* 0.7 x)))) (* 1.2 (sqrt (abs x))))
(- 0.21 x)
hw
hh))))
(defdemo recurrence-demo "Recurrence" ()
10 10 700 700
"Plots a cool recurrence relation."
(recurrence *display* *window*))
!
;;;; Plaid
;;;
;;; Translated from the X11 Plaid Demo written in C by Christopher Hoover.
;;;
(defmacro rect-x (rects n)
`(svref ,rects (ash ,n 2)))
(defmacro rect-y (rects n)
`(svref ,rects (+ (ash ,n 2) 1)))
(defmacro rect-width (rects n)
`(svref ,rects (+ (ash ,n 2) 2)))
(defmacro rect-height (rects n)
`(svref ,rects (+ (ash ,n 2) 3)))
(defun plaid (display window &optional (num-iterations 10000) (num-rectangles 10))
(let ((gcontext (xlib:create-gcontext :drawable window
:function boole-c2
:plane-mask (logxor *white-pixel*
*black-pixel*)
:background *white-pixel*
:foreground *black-pixel*
:fill-style :solid))
(rectangles (make-array (* 4 num-rectangles)
:element-type 'number
:initial-element 0)))
(multiple-value-bind (width height) (full-window-state window)
(let ((center-x (ash width -1))
(center-y (ash height -1))
(x-dir -2)
(y-dir -2)
(x-off 2)
(y-off 2))
(dotimes (iter (truncate num-iterations num-rectangles))
(dotimes (i num-rectangles)
(setf (rect-x rectangles i) (- center-x x-off))
(setf (rect-y rectangles i) (- center-y y-off))
(setf (rect-width rectangles i) (ash x-off 1))
(setf (rect-height rectangles i) (ash y-off 1))
(incf x-off x-dir)
(incf y-off y-dir)
(when (or (<= x-off 0) (>= x-off center-x))
(decf x-off (ash x-dir 1))
(setf x-dir (- x-dir)))
(when (or (<= y-off 0) (>= y-off center-y))
(decf y-off (ash y-dir 1))
(setf y-dir (- y-dir))))
(xlib:draw-rectangles window gcontext rectangles t)
(xlib:display-force-output display))))
(xlib:free-gcontext gcontext)))
(defdemo plaid-demo "Plaid" (&optional (iterations 10000) (num-rectangles 10))
10 10 101 201
"Plaid, man."
(plaid *display* *window* iterations num-rectangles))
!
;;;; Bball demo
;;;
;;; Ported to CLX by Blaine Burks
;;;
(defvar *ball-size-x* 38)
(defvar *ball-size-y* 34)
(defmacro xor-ball (pixmap window gcontext x y)
`(xlib:copy-area ,pixmap ,gcontext 0 0 *ball-size-x* *ball-size-y*
,window ,x ,y))
(defconstant bball-gravity 1)
(defconstant maximum-x-drift 7)
(defvar *max-bball-x*)
(defvar *max-bball-y*)
(defstruct ball
(x (random (- *max-bball-x* *ball-size-x*)))
(y (random (- *max-bball-y* *ball-size-y*)))
(dx (if (zerop (random 2)) (random maximum-x-drift)
(- (random maximum-x-drift))))
(dy 0))
(defun get-bounce-image ()
"Returns the pixmap to be bounced around the screen."
(xlib::bitmap-image #*000000000000000000000000000000000000
#*000000000000000000000000000000000000
#*000000000000000000001000000010000000
#*000000000000000000000000000100000000
#*000000000000000000000100001000000000
#*000000000000000010000000010000000000
#*000000000000000000100010000000000000
#*000000000000000000001000000000000000
#*000000000001111100000000000101010000
#*000000000010000011000111000000000000
#*000000000100000000111000000000000000
#*000000000100000000000000000100000000
#*000000000100000000001000100010000000
#*000000111111100000010000000001000000
#*000000111111100000100000100000100000
#*000011111111111000000000000000000000
#*001111111111111110000000100000000000
#*001111111111111110000000000000000000
#*011111111111111111000000000000000000
#*011111111111111111000000000000000000
#*111111111111110111100000000000000000
#*111111111111111111100000000000000000
#*111111111111111101100000000000000000
#*111111111111111101100000000000000000
#*111111111111111101100000000000000000
#*111111111111111111100000000000000000
#*111111111111110111100000000000000000
#*011111111111111111000000000000000000
#*011111111111011111000000000000000000
#*001111111111111110000000000000000000
#*001111111111111110000000000000000000
#*000011111111111000000000000000000000
#*000000111111100000000000000000000000
#*000000000000000000000000000000000000))
(defun bounce-1-ball (pixmap window gcontext ball)
(let ((x (ball-x ball))
(y (ball-y ball))
(dx (ball-dx ball))
(dy (ball-dy ball)))
(xor-ball pixmap window gcontext x y)
(setq x (+ x dx))
(setq y (+ y dy))
(if (or (< x 0) (> x (- *max-bball-x* *ball-size-x*)))
(setq x (- x dx)
dx (- dx)))
(if (> y (- *max-bball-y* *ball-size-y*))
(setq y (- y dy)
dy (- dy)))
(setq dy (+ dy bball-gravity))
(setf (ball-x ball) x)
(setf (ball-y ball) y)
(setf (ball-dx ball) dx)
(setf (ball-dy ball) dy)
(xor-ball pixmap window gcontext x y)))
(defun bounce-balls (display window how-many duration)
(xlib:clear-area window)
(xlib:display-force-output display)
(multiple-value-bind (*max-bball-x* *max-bball-y*) (full-window-state window)
(let* ((balls (do ((i 0 (1+ i))
(list () (cons (make-ball) list)))
((= i how-many) list)))
(gcontext (xlib:create-gcontext :drawable window
:foreground *white-pixel*
:background *black-pixel*
:function boole-xor
:exposures :off))
(bounce-pixmap (xlib:create-pixmap :width 38 :height 34 :depth 1
:drawable window))
(pixmap-gc (xlib:create-gcontext :drawable bounce-pixmap
:foreground *white-pixel*
:background *black-pixel*)))
(xlib:put-image bounce-pixmap pixmap-gc (get-bounce-image)
:x 0 :y 0 :width 38 :height 34)
(xlib:free-gcontext pixmap-gc)
(dolist (ball balls)
(xor-ball bounce-pixmap window gcontext (ball-x ball) (ball-y ball)))
(xlib:display-force-output display)
(dotimes (i duration)
(dolist (ball balls)
(bounce-1-ball bounce-pixmap window gcontext ball))
(xlib:display-force-output display))
(xlib:free-pixmap bounce-pixmap)
(xlib:free-gcontext gcontext))))
(defdemo bouncing-ball-demo "Bouncing-Ball" (&optional (how-many 5) (duration 500))
34 34 700 500
"Bouncing balls in space."
(bounce-balls *display* *window* how-many duration))
∂12-Jun-89 1340 CL-Windows-mailer Flushing the event queue
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 12 Jun 89 13:40:42 PDT
Return-Path: <singer@Think.COM>
Received: from leander.think.com by Think.COM; Mon, 12 Jun 89 16:40:41 EDT
Received: by leander.think.com; Mon, 12 Jun 89 16:39:34 EDT
Date: Mon, 12 Jun 89 16:39:34 EDT
From: singer@Think.COM
Message-Id: <8906122039.AA12404@leander.think.com>
To: cl-windows@sail.stanford.edu
Subject: Flushing the event queue
How does one flush the event queue in CLX?
Is there anything in the way of event handling documentation? A
draft, a few notes, something on the back of an envelope? Anything at all?
I'm getting all sorts of wierd event behavior that is surely the result of
my not knowing what I was doing. Anyone have anything I can look at? Even
a well-documented example of something that has lots of windows with lots
of different event-masks...
Alex Singer
Thinking Machines Corp.
∂12-Jun-89 1718 CL-Windows-mailer Re: Flushing the event queue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 17:17:59 PDT
Received: by ti.com id AA05985; Mon, 12 Jun 89 19:18:33 CDT
Received: from dsg by tilde id AA21319; Mon, 12 Jun 89 19:03:50 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 12 Jun 89 19:01:03 CDT
Message-Id: <2822688007-7417474@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Mon, 12 Jun 89 19:00:07 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: singer@Think.COM
Cc: cl-windows@sail.stanford.edu
Subject: Re: Flushing the event queue
In-Reply-To: Msg of Mon, 12 Jun 89 16:39:34 EDT from singer@Think.COM
> How does one flush the event queue in CLX?
(event-case (display :timeout 0 :discard-p t))
∂13-Jun-89 0331 CL-Windows-mailer Mail address
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 13 Jun 89 03:31:43 PDT
Received: from germany.csnet by RELAY.CS.NET id ad10646; 13 Jun 89 6:31 EDT
Received: from uklirb by iraun1.ira.uka.de id aa19992; 13 Jun 89 10:49 MET DST
Date: Tue, 13 Jun 89 10:44:21 MET DST
From: Gebhard Przyrembel <przy@uklirb.uucp>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Mail address
Please change my e-mail-address to
ki=clx@unido.uucp
Thanks in Advance,
Gebhard
/---------------------------------------------------------\
| e-mail: przy@uklirb.UUCP |
| Real-Name: Gebhard Przyrembel |
| University Kaiserslautern |
| Departement of Computer Science |
| AG Siekmann |
| D-6750 Kaiserslautern |
| West-Germany |
\---------------------------------------------------------/
∂13-Jun-89 0921 CL-Windows-mailer CLX Speed: Pretty poor
Received: from A.GP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 89 09:21:05 PDT
Date: Tuesday, 13 June 1989 12:21:03 EDT
From: Brad.Myers@a.gp.cs.cmu.edu
To: cl-windows@sail.stanford.edu
cc: bam@a.gp.cs.cmu.edu, koz@b.gp.cs.cmu.edu
Subject: CLX Speed: Pretty poor
Message-ID: <1989.6.13.16.2.17.Brad.Myers@A.GP.CS.CMU.EDU>
We ran some tests to see how fast CLX is, and it isn't. Compared to
calling the X routines from C, CLX is **approximately 15 times slower**
(1500% slower). This is running the standard CLX under CMU CommonLisp
on IBM RTs with X11R3. My impression is the Lucid CLX is not faster (and
may be even slower).
* Does anyone know if CLX is going to get faster? (Please, please!)
* Is there some way to write this code better?
* Is CLX on some other machines faster? (I challenge you to execute this
test yourself and see!)
We are trying to have complex objects follow the mouse around without lagging.
-----
Below are the descriptions of the tests, the results, and then the actual
code we used in Lisp and in C.
-----
Thanks to Dave Kosbie for running these tests!
-----
Brad A. Myers
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15213-3890
(412) 268-5150
bam@a.gp.cs.cmu.edu
-----------
Test1: Repeatedly writing a rectangle to the window, and flushing the output
after each call.
Test2: This is Test1, but the flush occurs only once, at the end.
Test3: Same as Test1, but I change the color of the rectangle on each call,
thus forcing X to play with the GC's somehow.
Test4: Same as Test1, but I set 10 fields of the gcontext before each write
(they are always being set to the same value, though...).
Test5: Same as Test1, but erases the old rectangle along the way (there is
still one flush per move, but now there are two draw-rectangle's
per move...).
Test6: Same as Test5, but also sets the 10 fields of gcontext before each
call to draw-rectangle (there are 2 calls to draw-rectangle per
move!). *** This timing is closest to what we are doing now in our
application.
The Moves/Second is the number of rectangles that can be drawn (or
drawn and erased) per second (so bigger numbers are better).
The Bytes/Move is the number of cons
cells allocated (why are there any at all?). Only two of the tests have
been run in C so far.
Moves/Second Lisp/C Comparison
Moves/Second Bytes/Move in C (moves/sec)
------------ ---------- -------------- -----------
Test1 129.5 32 1860.5 x14.37
Test2 930.0 32
Test3 114.9 40
Test4 104.7 64
Test5 89.1 80 1465.2 x16.44
Test6 72.2 144
Here follows the Lisp code which produced these results:
----------------------------------------------------------------------------
;;(in-package "TEST-BAM" :nicknames '("TB") :use '("LISP"))
(defmacro finish() '(xlib:display-finish-output d))
(defmacro map() '(progn (xlib:map-window xw) (finish)))
(defmacro unmap() '(progn (xlib:unmap-window xw) (finish)))
(defmacro rect(x y w h) `(progn (xlib:draw-rectangle xw gc ,x ,y ,w ,h t)
(finish)))
(defmacro rect1(x y w h) `(progn (xlib:draw-rectangle xw gc ,x ,y ,w ,h nil)
(finish)))
(defun g()
(setq d (xlib:open-display (machine-instance)))
(setq s (xlib:display-default-screen d))
(setq root (xlib:screen-root s))
(setq black (xlib:screen-black-pixel s))
(setq white (xlib:screen-white-pixel s))
(setq xw (xlib:create-window :parent root :x 870 :y 450 :event-mask nil
:width 150 :height 50 :background white :border black
:border-width 2 :override-redirect :on))
(map)
(setq gc (xlib:create-gcontext :drawable xw :background white
:foreground black :fill-style :solid))
t
)
(defun test(n &optional (gc-p nil))
(xlib:with-gcontext (gc :foreground white) (rect 0 0 150 50))
(let ((x 1) (y 1) (fore black))
(rect 1 1 20 20)
(if gc-p (lisp::gc))
(time
(dotimes (z n)
(when (> (setq x (+ x 5)) 125)
(setq x 1)
(when (> (setq y (+ y 5)) 25)
(setq y 1)))
;; (setf (xlib:gcontext-foreground gc)
;; (setq fore (- 1 fore)))
(rect x y 20 20)))
(setf (xlib:gcontext-foreground gc) black)))
(defun s()
(unmap)
(xlib::free-gcontext gc)
)
----------------------------------------------------------------------------
Here follows the C code which produced these results:
----------------------------------------------------------------------------
/*
to compile: cc testbam.c -lX11
*/
#include <stdio.h>
#include <X11/X.h>
#include <X11/Xlib.h>
extern char *getenv();
#define finish() XFlush(d)
#define map() { XMapWindow(d,xw); finish(); }
#define unmap() { XUnmapWindow(d,xw); finish(); }
#define rect1(x y w h) XFillRectangle(d,xw,gc1,x,y,w,h)
#define rect(x y w h) { XFillRectangle(d,xw,gc1,x,y,w,h); finish(); }
Display *d;
Screen *s;
Window root;
unsigned long black, white;
Window xw;
GC gc1,gc2;
XSetWindowAttributes *set_attributes()
{
XSetWindowAttributes *result;
result = (XSetWindowAttributes *)malloc(sizeof(XSetWindowAttributes));
result->override_redirect = 1;
result->background_pixel = white;
return(result);
}
XGCValues *set_gc(n)
int n;
{
XGCValues *result;
result = (XGCValues *)malloc(sizeof(XGCValues));
result->background = ((n == 1) ? white : black);
result->foreground = ((n == 1) ? black : white);
result->fill_style = FillSolid;
return(result);
}
void g()
{
char *display;
if ((display = getenv("DISPLAY")) == NULL)
{ fprintf(stderr,"Oops! DISPLAY set to NULL!\n",display);
exit(1);
}
if ((d = XOpenDisplay(display)) == NULL)
{ fprintf(stderr,"Oops! Could not open display %s\n",display);
exit(1);
}
s = XDefaultScreenOfDisplay(d);
root = XRootWindowOfScreen(s);
black = XBlackPixelOfScreen(s);
white = XWhitePixelOfScreen(s);
xw = XCreateWindow(d,root,1,1,500,500,2,0,InputOutput,CopyFromParent,
(CWOverrideRedirect | CWBackPixel),set_attributes());
map();
gc1 = XCreateGC(d,xw,(GCBackground | GCForeground | GCFillStyle),set_gc(1));
gc2 = XCreateGC(d,xw,(GCBackground | GCForeground | GCFillStyle),set_gc(2));
}
void test(n)
int n;
{
int x, y, count, old_x, old_y;
old_x = old_y = x = y = 1;
rect(1,1,20,20);
for (count=0;count<n;count++)
{ if ((x = x+5) > 475)
{ x = 1;
if ((y = y+5) > 475)
y = 1;
}
/* XSetForeground(d,gc,white); */
XFillRectangle(d,xw,gc2,old_x,old_y,20,20);
/* XSetForeground(d,gc,black); */
old_x = x; old_y = y;
rect(x,y,20,20);
}
XSetForeground(d,gc1,black);
}
/*
(defun s()
(unmap)
(xlib::free-gcontext gc1)
(xlib::free-gcontext gc2)
)
*/
main(argc,argv)
int argc;
char *argv[];
{
int times;
if (argc > 1) sscanf(argv[1],"%d",×);
if (times < 1) times = 400;
printf("Testing for %0d times\n",times);
g();
test(times);
}
∂13-Jun-89 1049 CL-Windows-mailer CLX Speed: Pretty poor
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Jun 89 10:49:13 PDT
Received: by ti.com id AA12908; Tue, 13 Jun 89 12:49:55 CDT
Received: from stroke.csc.ti.com by tilde id AA12182; Tue, 13 Jun 89 12:43:59 CDT
Received: by stroke.csc.ti.com (4.0/SMI-4.0)
id AA01481; Tue, 13 Jun 89 12:43:53 CDT
Date: Tue, 13 Jun 89 12:43:53 CDT
From: oren@stroke.csc.ti.com (LaMott Oren)
Message-Id: <8906131743.AA01481@stroke.csc.ti.com>
To: Brad.Myers@a.gp.cs.cmu.edu
Cc: cl-windows@sail.stanford.edu, bam@a.gp.cs.cmu.edu, koz@b.gp.cs.cmu.edu
In-Reply-To: Brad.Myers@a.gp.cs.cmu.edu's message of Tuesday, 13 June 1989 12:21:03 EDT <1989.6.13.16.2.17.Brad.Myers@A.GP.CS.CMU.EDU>
Subject: CLX Speed: Pretty poor
Date: Tuesday, 13 June 1989 12:21:03 EDT
From: Brad.Myers@a.gp.cs.cmu.edu
We ran some tests to see how fast CLX is, and it isn't. Compared to
calling the X routines from C, CLX is **approximately 15 times slower**
(1500% slower). This is running the standard CLX under CMU CommonLisp
on IBM RTs with X11R3. My impression is the Lucid CLX is not faster (and
may be even slower).
The C and Lisp codes are NOT equivalent. The inner loop of the C code calls
XFillRectangle followed by XFlush. The inner loop of the Lisp code calls
draw-rectangle (which IS equivalent) followed by display-finish-output (which
is equivalent to XSync). Therefore, the Lisp code is doing a server round-trip
for every rectangle!!
* Does anyone know if CLX is going to get faster? (Please, please!)
By default, CLX checks almost all function argument types. You can turn this
feature off and get significant code shrinkage and speedups. Change
(defconstant *type-check?* t)
in the dependent.l file to
(defconstant *type-check?* nil)
By the way, the comments say you can set *type-check?* to :minimal, but it
lies. Most of the code checks for *type-check?* being null.
Another thing that can slow you down is if you're using the default
xlib::buffer-write-default function provided by CLX in the dependent.l file.
This function writes data to the server one byte at a time. Release 3 CLX has
code for lisp machines and Lucid to write blocks of words. Release 4 CLX will
have similar code for Franz. I encourage you to write similar code for CMU
CommonLisp, and also to replace the default xlib::buffer-read-default.
A third think I have no way of checking on is your connection to the server.
Is the lisp code always going through TCP/IP, or does it pipe to the local
server?
* Is there some way to write this code better?
YES, don't use display-finish-output. Use:
(defmacro finish() '(xlib:display-force-output d))
* Is CLX on some other machines faster? (I challenge you to execute this
test yourself and see!)
I'm sure it's faster on a Lisp machine (TI Explorer or Symbolics)
∂13-Jun-89 1105 CL-Windows-mailer Re: CLX Speed: Pretty poor
Received: from CHILES.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 89 11:05:48 PDT
Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 13 Jun 89 14:05:16 EDT
To: Brad.Myers@A.GP.CS.CMU.EDU
cc: cl-windows@sail.stanford.edu, bam@A.GP.CS.CMU.EDU,
koz@B.GP.CS.CMU.EDU
Subject: Re: CLX Speed: Pretty poor
In-reply-to: Your message of Tue, 13 Jun 89 12:21:03 -0400.
<1989.6.13.16.2.17.Brad.Myers@A.GP.CS.CMU.EDU>
Date: Tue, 13 Jun 89 14:04:54 EDT
Message-ID: <16694.613764294@CHILES.SLISP.CS.CMU.EDU>
From: Bill.Chiles@WB1.CS.CMU.EDU
One obvious problem is that the C code is forcing output while the Lisp
code is finishing output. In the C code you are just dumping the buffered
requests on the pipe to the server, while the Lisp code is doing this and
then waiting for the server to come back and say "Okay". This means the
server must run and return to Lisp, switching contexts twice. On an RT
running Mach, this is pretty blecherous.
Bill
∂13-Jun-89 1303 CL-Windows-mailer An example of following the mouse with CLX
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Jun 89 13:03:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22917; Tue, 13 Jun 89 13:04:57 PDT
Message-Id: <8906132004.AA22917@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-windows@sail.stanford.edu; id AA22917; Tue, 13 Jun 89 13:04:57 PDT
From: lowry%aitg.DEC@decwrl.dec.com (David Lowry, VAX LISP 291-8070)
Date: 13 Jun 89 16:00
To: cl-windows@sail.stanford.edu
Subject: An example of following the mouse with CLX
I munged this together to show how to actually see how fast CLX
could follow the mouse. Note I only call force-output when I need
to, and avoid finish-output. Also I don't set :override-redirect
on the window, set it if you want.
David Lowry
-------------------------- cut here ------------------------
;;;This puts up a window and then follows the pointer with a small
;;;rectangle. Compile and load and call follow-mouse.
;;;
;;;
;;; DDL
;;;
;;set this to your host if you're running over a network
(defvar *machine* nil)
(defun init-window ()
(declare (special d s root black white xw gc erase-gc))
(setq d (xlib:open-display (or *machine* (machine-instance))))
(setq s (xlib:display-default-screen d))
(setq root (xlib:screen-root s))
(setq black (xlib:screen-black-pixel s))
(setq white (xlib:screen-white-pixel s))
(setq xw (xlib:create-window :parent root :x 10 :y 10 :event-mask
'(:pointer-motion :button-press)
:width 600 :height 600 :background white :border black
:border-width 2))
(setq gc (xlib:create-gcontext :drawable xw :background white
:foreground black :fill-style :solid))
(setq erase-gc (xlib:create-gcontext :drawable xw :background black
:foreground white :fill-style :solid))
t)
(defun rect (gc x y solid?)
(xlib:draw-rectangle xw gc x y 20 20 solid?))
;;simply waits for motion events, erases the old rectangle and draws
;;a new one where the pointer is. Click a button to exit.
(defun follow-mouse (&optional (solid? nil))
(declare (special d xw gc erase-gc))
(unless d (init-window))
(xlib:map-window xw)
(let ((old-x 0)
(old-y 0))
(xlib:event-case (d :discard-p t :force-output-p t)
(motion-notify (x y)
(rect erase-gc old-x old-y solid?)
(rect gc x y solid?)
(setq old-x x old-y y)
(xlib:display-force-output d)
nil)
(button-press () t)))
(xlib:unmap-window xw)
(xlib:display-force-output d))
∂13-Jun-89 1314 CL-Windows-mailer Re: CLX Speed: Pretty poor
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 13 Jun 89 13:14:17 PDT
Received: from franz.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA20345; Tue, 13 Jun 89 16:14:36 -0400
Received: by franz.franz.uucp (MC 2.0/FI-0.97)
id AA04675; Tue, 13 Jun 89 12:29:32 PDT
Received: by sparky.franz.uucp (4.0/FI-0.97)
id AA04346; Tue, 13 Jun 89 12:24:23 PDT
Message-Id: <8906131924.AA04346@sparky.franz.uucp>
To: Brad.Myers@a.gp.cs.cmu.edu
Cc: cl-windows@sail.stanford.edu, bam@a.gp.cs.cmu.edu, koz@b.gp.cs.cmu.edu
Subject: Re: CLX Speed: Pretty poor
In-Reply-To: Your message of Tue, 13 Jun 89 12:21:03 -0400.
<1989.6.13.16.2.17.Brad.Myers@A.GP.CS.CMU.EDU>
Date: Tue, 13 Jun 89 12:24:22 -0700
From: John Irwin <franz!jdi@uunet.UU.NET>
Your message:
We ran some tests to see how fast CLX is, and it isn't. Compared to
calling the X routines from C, CLX is **approximately 15 times slower**
(1500% slower). This is running the standard CLX under CMU CommonLisp
on IBM RTs with X11R3. My impression is the Lucid CLX is not faster (and
may be even slower).
...
* Is CLX on some other machines faster? (I challenge you to execute this
test yourself and see!)
...
The Moves/Second is the number of rectangles that can be drawn (or
drawn and erased) per second (so bigger numbers are better).
The Bytes/Move is the number of cons
cells allocated (why are there any at all?). Only two of the tests have
been run in C so far.
Moves/Second Lisp/C Comparison
Moves/Second Bytes/Move in C (moves/sec)
------------ ---------- -------------- -----------
Test1 129.5 32 1860.5 x14.37
Test2 930.0 32
Test3 114.9 40
Test4 104.7 64
Test5 89.1 80 1465.2 x16.44
Test6 72.2 144
...
Here follows the Lisp code which produced these results:
...
Does the code you sent correspond to test 1?
I changed the "display-finish-output" to "display-force-output" and ran it
on a sun4/260 using Franz Allegro CL 3.1beta, and May Day CLX. Display
was "unix:0".
I got about 3500 "moves"/cpu second, and no consing.
-- John Irwin, jdi@franz.com
∂13-Jun-89 1314 CL-Windows-mailer Re: CLX Speed: Pretty poor
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 13 Jun 89 13:14:41 PDT
Received: from franz.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA20361; Tue, 13 Jun 89 16:14:50 -0400
Received: by franz.franz.uucp (MC 2.0/FI-0.97)
id AA04721; Tue, 13 Jun 89 12:43:11 PDT
Received: by sparky.franz.uucp (4.0/FI-0.97)
id AA04377; Tue, 13 Jun 89 12:38:04 PDT
Message-Id: <8906131938.AA04377@sparky.franz.uucp>
To: oren@stroke.csc.ti.com (LaMott Oren)
Cc: Brad.Myers@a.gp.cs.cmu.edu, cl-windows@sail.stanford.edu,
bam@a.gp.cs.cmu.edu, koz@b.gp.cs.cmu.edu
Subject: Re: CLX Speed: Pretty poor
In-Reply-To: Your message of Tue, 13 Jun 89 12:43:53 -0500.
<8906131743.AA01481@stroke.csc.ti.com>
Date: Tue, 13 Jun 89 12:38:03 -0700
From: John Irwin <franz!jdi@uunet.UU.NET>
Your message:
...
By default, CLX checks almost all function argument types. You can turn thi
s
feature off and get significant code shrinkage and speedups. Change
(defconstant *type-check?* t)
in the dependent.l file to
(defconstant *type-check?* nil)
By the way, the comments say you can set *type-check?* to :minimal, but it
lies. Most of the code checks for *type-check?* being null.
Another thing that can slow you down is if you're using the default
xlib::buffer-write-default function provided by CLX in the dependent.l file
.
This function writes data to the server one byte at a time. Release 3 CLX
has
code for lisp machines and Lucid to write blocks of words. Release 4 CLX w
ill
have similar code for Franz. I encourage you to write similar code for CMU
CommonLisp, and also to replace the default xlib::buffer-read-default.
...
--------
Small correction here. Since X11 Release 2, a year and a half ago, CLX has
had code to allow Franz CL to read and write whole blocks at a time.
Since Release 3 there have been some additional improvements -- these are
in May Day CLX, available via public ftp from ucbarpa.berkeley.edu.
Also in May Day CLX is code to make Franz CL type checking fast enough so that
you don't have to bother turning it off. If you turn it off and send a bad
value to the server you get a server error back, which is a lot less friendly
than getting an error before you send the request.
-- John Irwin, jdi@franz.com
∂15-Jun-89 1405 CL-Windows-mailer gcontext and draw-foo with white-pixel foreground??
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 15 Jun 89 14:05:45 PDT
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.61/Ultrix2.0-B)
id AA08518; Thu, 15 Jun 89 17:10:31 -0400
Message-Id: <8906152110.AA08518@crash.cs.umass.edu>
Date: Thu, 15 Jun 89 17:05 EST
From: BROLIO@cs.umass.EDU
Subject: gcontext and draw-foo with white-pixel foreground??
To: cl-windows@sail.stanford.EDU
X-Vms-To: LISPX
I have a strange problem with xlib:draw-rectangle. Perhaps
someone will recognize it and tell me what's going on.
The first time I call draw-rectangle in a program, I set
gcontext-foreground to screen-white-pixel and try to draw a
white rectangle on a black background. For some reason
what I am getting is a black rectangle on a black background.
What I have to do is set gcontext-foreground to
black-pixel, draw a rectangle, THEN set gcontext-foreground
to white-pixel and draw the rectangle I want. I spent a
day trying other things to figure out what was happening
(i.e., fiddling with set-window-background, etc.). Nothing
else helped.
I have a sneaking suspicion that it might be something
in draw-rectangle which is doing some interesting stuff
appending requests. Anyone have an idea?
John Brolio
(413) 545-3279
brolio@cs.umass.edu
∂16-Jun-89 0549 CL-Windows-mailer Re: gcontext and draw-foo with white-pixel foreground??
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 16 Jun 89 05:48:58 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Fri, 16 Jun 89 08:49:37 EDT
Received: by expire.lcs.mit.edu; Fri, 16 Jun 89 08:49:35 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8906161249.AA00929@expire.lcs.mit.edu>
To: BROLIO@cs.umass.edu
Cc: cl-windows@sail.stanford.edu
Subject: Re: gcontext and draw-foo with white-pixel foreground??
In-Reply-To: Your message of Thu, 15 Jun 89 17:05:00 EST.
<8906152110.AA08518@crash.cs.umass.edu>
Date: Fri, 16 Jun 89 08:49:34 -0400
Please provide (me) an actual code example to demonstrate the problem, and
also indicate what release of CLX, what CL, what release of X server, and what
server hardware you are running on.
∂16-Jun-89 0825 CL-Windows-mailer Re: XLIB:DISPLAY-NSCREENS seems broken in R3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Jun 89 08:24:43 PDT
Received: by ti.com id AA10367; Fri, 16 Jun 89 08:48:11 CDT
Received: from dsg by tilde id AA04569; Fri, 16 Jun 89 08:44:34 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 16 Jun 89 08:41:39 CDT
Message-Id: <2822996414-1955024@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 16 Jun 89 08:40:14 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: XLIB:DISPLAY-NSCREENS seems broken in R3
In-Reply-To: Msg of Thu, 15 Jun 89 14:51:06 -0700 from John Irwin <franz!jdi@uunet.uu.net>
> XLIB:DISPLAY-NSCREENS does not appear to return the correct number of scree
> ns
> that a display has in R3. Is this a known bug ?
>
>
> This happened on Genera 7.2.
>
> > (setq p (xlib:open-display "prom"))
> #<XLIB:DISPLAY prom 0 434000020>
> > (xlib:display-nscreens p)
> 1
> > (xlib:display-roots p)
> (#S(XLIB:SCREEN...) #S(XLIB:SCREEN ...))
>
> -- jim
> salem@think.com
> --------
>
> Looks like you're the first person ever to use it! :-\
> It's default value is 1, and it is never set.
>
> Personally I think it should be removed entirely. It seems pretty simple
> to just use:
>
> (length (xlib:display-roots display))
>
> which is equivalent, no?
>
> -- John
Agreed.
∂19-Jun-89 1641 CL-Windows-mailer Please add me to the mailing list (cl-windows@sail.stanford.edu)
Received: from uxc.cso.uiuc.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 16:41:09 PDT
Received: from convex.UUCP by uxc.cso.uiuc.edu with UUCP
(5.61+/IDA-1.2.8) id AA04931; Mon, 19 Jun 89 17:36:11 -0500
Received: by convex (5.51/4.7)
id AA09308; Mon, 19 Jun 89 17:37:06 CDT
Message-Id: <8906192237.AA23105@convex1>
To: cl-windows@sail.stanford.edu
Cc: convex1!golan
Subject: Please add me to the mailing list (cl-windows@sail.stanford.edu)
Date: Mon, 19 Jun 89 17:37:01 CDT
From: Dan Golan <convex!golan@uxc.cso.uiuc.edu>
Sorry if this is a duplicate request.
I tried last week and haven't seen any messages yet.
===============================================================================
Dan Golan
Third Party Applications Specialist
Convex Computer Corporation fax: (214) 497-4848
P.O. Box 833851 uucp: golan@convex.com
Richardson, Texas 75083-3851 (U.S.A.) phone: (214) 497-4281
∂28-Jun-89 1636 CL-Windows-mailer CLX Speed: Pretty poor
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 28 Jun 89 16:36:45 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 618512; 28 Jun 89 19:01:47 EDT
Date: Wed, 28 Jun 89 19:01 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLX Speed: Pretty poor
To: LaMott Oren <oren@stroke.csc.ti.com>, Brad.Myers@a.gp.cs.cmu.edu
cc: cl-windows@sail.stanford.edu, bam@a.gp.cs.cmu.edu, koz@b.gp.cs.cmu.edu
In-Reply-To: <8906131743.AA01481@stroke.csc.ti.com>
Message-ID: <19890628230133.4.MMCM@OWL.SCRC.Symbolics.COM>
Date: Tue, 13 Jun 89 12:43:53 CDT
From: oren@stroke.csc.ti.com (LaMott Oren)
Date: Tuesday, 13 June 1989 12:21:03 EDT
From: Brad.Myers@a.gp.cs.cmu.edu
We ran some tests to see how fast CLX is, and it isn't. Compared to
calling the X routines from C, CLX is **approximately 15 times slower**
(1500% slower). This is running the standard CLX under CMU CommonLisp
on IBM RTs with X11R3. My impression is the Lucid CLX is not faster (and
may be even slower).
The C and Lisp codes are NOT equivalent. The inner loop of the C code calls
XFillRectangle followed by XFlush. The inner loop of the Lisp code calls
draw-rectangle (which IS equivalent) followed by display-finish-output (which
is equivalent to XSync). Therefore, the Lisp code is doing a server round-trip
for every rectangle!!
Actually, that's not all.
There is the evidently gratuituous difference in the size and position
of the windows which makes comparison difficult. There is the lack of
DEFVAR's for the globals in the LISP, which makes compilation noisy.
There is the lack of a cast of CopyFromParent to a (Visual *) required
by ANSI compilers (CopyFromParent being just 0).
But most significantly, the C code draws twice as many rectangles. It
draws one in white at the old position. The LISP code only draws in
black in the new position. No doubt the unjustified differences
mentioned above and the inconsistent use of macros make it hard to spot
this until you run them both.
I'm sure it's faster on a Lisp machine (TI Explorer or Symbolics)
As submitted, the LISP runs about 1.5 times faster, since it has less
work to do! When you correct that, they run about the same on an Ivory.
The actual numbers aren't really meaningful, since the server I used
happened not to be on the same processor. But the client communications
path was the same.
∂29-Jun-89 1002 CL-Windows-mailer xlib:<mumble>-equal
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Jun 89 10:02:23 PDT
Received: by ti.com id AA21455; Thu, 29 Jun 89 12:02:39 CDT
Received: from dsg by tilde id AA00965; Thu, 29 Jun 89 11:57:51 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 29 Jun 89 11:53:06 CDT
Message-Id: <2824131132-9515278@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 29 Jun 89 11:52:12 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: xlib:<mumble>-equal
The specification for these predicates is not clear. Should they return true iff
the two drawable/font/gcontext/etc. objects are EQ (the current implementation)?
Or should they return true iff the two objects name the same server resource?
The mere existence of these functions implies that the latter definition was
intended. This might be implemented as:
(defun mumble-equal (mumble1 mumble2)
(and
(eq
(mumble-id mumble1)
(mumble-id mumble2))
(display-equal
(mumble-display mumble1)
(mumble-display mumble2))))
where:
(defun display-equal (display1 display2)
(and
(equalp
(display-host display1)
(display-host display2))
(=
(display-display display1)
(display-display display2))))
∂29-Jun-89 1213 CL-Windows-mailer Re: xlib:<mumble>-equal
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 29 Jun 89 12:12:58 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA24535; Thu, 29 Jun 89 15:13:20 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA00789; Thu, 29 Jun 89 11:17:26 PDT
Received: by sparky.Franz.COM (4.0/FI-1.0)
id AA11531; Thu, 29 Jun 89 11:16:09 PDT
Message-Id: <8906291816.AA11531@sparky.Franz.COM>
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: xlib:<mumble>-equal
In-Reply-To: Your message of Thu, 29 Jun 89 11:52:12 -0500.
<2824131132-9515278@Sierra>
Date: Thu, 29 Jun 89 11:16:07 -0700
From: John Irwin <jdi@Franz.COM>
Your message:
The specification for these predicates is not clear. Should they return
true iff the two drawable/font/gcontext/etc. objects are EQ (the current
implementation)?
Or should they return true iff the two objects name the same server
resource?
The mere existence of these functions implies that the latter definition
was intended...
--------
Here's the current implementation:
(defmacro make-mumble-equal (type)
;; When cached, EQ works fine, otherwise test resource id's and displays
(let ((predicate (xintern type '-equal))
(id (xintern type '-id))
(dpy (xintern type '-display)))
(if (member type *clx-cached-types*)
`(within-definition (,type make-mumble-equal)
(proclaim '(inline ,predicate))
(defun ,predicate (a b) (eq a b)))
`(within-definition (,type make-mumble-equal)
(defun ,predicate (a b)
(declare (type ,type a b))
(and (= (,id a) (,id b))
(eq (,dpy a) (,dpy b))))))))
Are you arguing that the final "eq" (for non cached objects) should be a
different test? Seems like two different (non-eq) displays couldn't have
equal objects, since they will have a different range of resource id's.
Or are you thinking that someone could copy a display object, and thus have
two display objects that reference the same socket?
Doesn't the current cacheing system guarantee that you will have only one
client object for each server object for objects that are cached?
-- John
∂02-Jul-89 1251 CL-Windows-mailer Re: xlib:<mumble>-equal
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 2 Jul 89 12:51:36 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Sun, 2 Jul 89 15:52:25 EDT
Received: by expire.lcs.mit.edu; Sun, 2 Jul 89 15:52:20 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8907021952.AA05906@expire.lcs.mit.edu>
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: xlib:<mumble>-equal
In-Reply-To: Your message of Thu, 29 Jun 89 11:52:12 CDT.
<2824131132-9515278@Sierra>
Date: Sun, 02 Jul 89 15:52:19 -0400
The specification for these predicates is not clear. Should they return
true iff the two drawable/font/gcontext/etc. objects are EQ (the current
implementation)? Or should they return true iff the two objects name the
same server resource?
EQness is implementation dependent. The -equal functions are provided to
test if they name the same resource on the same display. I do not believe
the issue of testing equality of objects obtained from two distinct connections
to the same X server was ever considered, so I would not be surprised to see
the implementation consider such objects as not equal.
∂03-Jul-89 1737 CL-Windows-mailer Re: xlib:<mumble>-equal
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Jul 89 17:36:52 PDT
Received: by ti.com id AA24904; Mon, 3 Jul 89 19:37:33 CDT
Received: from dsg by tilde id AA06391; Mon, 3 Jul 89 16:41:20 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 3 Jul 89 16:36:26 CDT
Message-Id: <2824493765-14787750@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Mon, 3 Jul 89 16:36:05 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: John Irwin <jdi@Franz.COM>
Cc: cl-windows@sail.stanford.edu
Subject: Re: xlib:<mumble>-equal
In-Reply-To: Msg of Thu, 29 Jun 89 11:16:07 -0700 from John Irwin <jdi@Franz.COM>
> Doesn't the current cacheing system guarantee that you will have only one
> client object for each server object for objects that are cached?
Yes. I didn't understand this before. I'm convinced now that the intended spec
is implemented correctly.
∂12-Jul-89 1110 CL-Windows-mailer mailing list
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 12 Jul 89 11:10:05 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA29442; Wed, 12 Jul 89 14:10:34 -0400
Received: by opal.STC.LOCKHEED.COM (3.2/1.46); Wed, 12 Jul 89 12:26:55 CDT
From: <SANTIAGO@DEDPC4.HAWK.DECNET.LOCKHEED.COM>
Received: by bluejay.STC.LOCKHEED.COM (3.2/1.4); Wed, 12 Jul 89 12:29:11 CDT
Date: Wed, 12 Jul 89 12:29:11 CDT
Message-Id: <8907121729.AA11936@bluejay.STC.LOCKHEED.COM>
Received: by DnaMail (v1.1)(dnamaild.c 1.13); Wed Jul 12 12:28:44 1989 CDT
X-Vms-To: HAWK::EAGLE::"cl-windows@sail.stanford.edu"
Subject: mailing list
To: cl-windows@sail.stanford.edu
Dear Sir,
I would like to be placed on your mailing lists. I am
particularly concerned with CLX related material and would like
to receive, if possible, all previous material related to this
subject.
We do not have the capability to do anonymous ftp, this is
a closed facility, and cannot get any material which may already
be there. But you can email everything to me, if possible.
Thank You,
R.J. Santiago
Lockheed Palo Alto Research Laboratory
email address is santiago@mvii.decnet.lockheed.com
∂12-Jul-89 1711 CL-Windows-mailer CLX for TI Explorer
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:11:13 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa05585; 12 Jul 89 20:11 EDT
Received: from cgi.com by RELAY.CS.NET id af18209; 12 Jul 89 20:07 EDT
Date: Wed, 12 Jul 89 18:39 EDT
From: Jake Kolojejchick <KOLOJEJCHICK@cgi.com>
Subject: CLX for TI Explorer
To: cl-windows%sail.stanford.edu@RELAY.CS.NET
X-VMS-To: IN%"cl-windows%sail.stanford.edu@relay.cs.net"
Has anyone gotten CLX to work on an Explorer using the DECNet protocol to
talk to DECWindows? I got the R3 CLX sources from MIT, and recompiled them
for the Explorer. When I loaded them it complained about:
ip::get-ip-address
ip::open-stream
not being defined. Looking in dependent.lisp it seems that the Explorer
ignores the value of protocol that is passed into open-x-stream. Am I doing
something wrong?
Can anyone offer advice or help in another form?
-jake
CSNet: kolojejchick@cgi.com
Internet: kolojejchick%cgi.com@relay.cs.net
∂14-Jul-89 1654 CL-Windows-mailer New CLUE available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Jul 89 16:54:08 PDT
Received: by ti.com id AA01130; Fri, 14 Jul 89 18:55:10 CDT
Received: from dsg by tilde id AA10495; Fri, 14 Jul 89 18:07:22 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 14 Jul 89 18:00:11 CDT
Message-Id: <2825449461-9197437@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 14 Jul 89 18:04:21 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
xpert@expo.lcs.mit.edu
Subject: New CLUE available
CLUE 6.0 is now available to the public via anonymous ftp. (Yes, the previous
version was called 1.15, but don't worry; you really aren't 5 versions behind.)
Anyone interested may receive source code and documentation via anonymous ftp
from CSC.TI.COM, (internet address 10.7.0.46) in /pub/clue.tar.Z. CLUE 6.0 will
also be part of the R4 distribution of the X Window System; see directory
contrib/toolkits/clue.
Please note that CLUE 6.0 depends on R3 CLX features and bug fixes (see R3
distribution, directory lib/CLX). The version of CLX found on CSC.TI.COM in
pub/clx.tar.Z is also sufficient to support CLUE 6.0. Be sure to review other
information found in clue/README and clue/doc/release.text.
CLUE (Common Lisp User Interface Environment) is a portable system for user
interface programming in Common Lisp. CLUE, which is based on the X Window
System and the Common Lisp Object System (CLOS), extends the CLX interface to
provide an architectural model for the construction of interactive Lisp
applications. Modelled on the Xt toolkit library, CLUE could be described as a
translation of the Xt "intrinsics" into the domain of Common Lisp and CLOS.
∂17-Jul-89 0647 CL-Windows-mailer Please remove me...
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 17 Jul 89 06:46:58 PDT
Received: by goddard.goldhill.com; Mon, 17 Jul 89 09:46:52 EDT
Date: Mon, 17 Jul 89 09:46:52 EDT
From: ejs@goldhill.com (Eric Swenson)
Message-Id: <8907171346.AA01936@goldhill.com>
To: cl-windows@sail.stanford.edu
Subject: Please remove me...
I'm receiving two copies of this mailing list. One is because I'm on the
redistribution list cl-windows-goldhill@goldhill.com. The other, I'm not
sure about. Do you have a mailing list entry for one of the following:
ejs@goldhill.com
ejs%acorn@live-oak.lcs.mit.edu
ejs@bco-multics.honeywell.hbi.com
Swenson@bco-multics.honeywell.hbi.com
If so, would you please inform me of this and remove the entry from the
cl-windows mailing list? Thanks. -- Eric
∂17-Jul-89 2254 CL-Windows-mailer New address for csc.ti.com
Received: from ti.com by SAIL.Stanford.EDU with TCP; 17 Jul 89 22:53:43 PDT
Received: by ti.com id AA21196; Mon, 17 Jul 89 13:48:04 CDT
Received: from dsg by tilde id AA14343; Mon, 17 Jul 89 13:34:09 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 17 Jul 89 13:26:48 CDT
Message-Id: <2825692265-7270352@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Mon, 17 Jul 89 13:31:05 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Subject: New address for csc.ti.com
csc.ti.com, the ftp host for access to CLUE, is no longer attached directly to
the Arpanet but is still available through the Internet. Please note that its
Internet address is now 128.247.159.141. Sorry for any confusion.
∂18-Jul-89 0208 CL-Windows-mailer CLUE lines are too long
Received: from ra.cs.ucla.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 02:08:33 PDT
Return-Path: <mujica@CS.UCLA.EDU>
Received: by ra.cs.ucla.edu (Sendmail 4.0/2.10)
id AA00480; Tue, 18 Jul 89 02:10:14 PDT
Date: Tue, 18 Jul 89 02:10:14 PDT
From: mujica@CS.UCLA.EDU (S. Mujica)
Message-Id: <8907180910.AA00480@ra.cs.ucla.edu>
To: Kimbrough@dsg.csc.ti.com
Cc: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu
Subject: CLUE lines are too long
I would suggest that the text files (such as clue/doc/release.text) be
formatted using lines shorter than 80 characters. It is often the
case that one needs to read these files from a terminal (like a
wyse-50). There are also cases in which people just do not like to
open wide windows in their workstations.
I would make the same suggestion for the code.
Sergio Mujica mujica@cs.ucla.edu
Computer Science Department, UCLA
∂25-Jul-89 1432 CL-Windows-mailer New colormap accessor
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Jul 89 14:32:07 PDT
Received: by ti.com id AA13329; Tue, 25 Jul 89 16:31:04 CDT
Received: from dsg by tilde id AA13800; Tue, 25 Jul 89 14:57:25 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 25 Jul 89 14:50:14 EDT
Message-Id: <2826381424-817115@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Tue, 25 Jul 89 13:57:04 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu
Subject: New colormap accessor
VERSION:
R3
CLIENT MACHINE and OPERATING SYSTEM:
n/a
DISPLAY:
n/a
WINDOW MANAGER:
n/a
AREA:
CLX
SYNOPSIS:
CLX should define a colormap-visual accessor to paper over a shortcoming of
the protocol.
DESCRIPTION:
After a colormap has been created, the X protocol does not allow a client to
query the server to return its visual type. But it's useful to know this
colormap attribute, since the behavior and even the validity of
alloc-color-cells, etc. depend on the class of the visual type.
FIX:
Store visual on colormap-plist when colormap is created. Define
colormap-visual accessor. Note: create-colormap also changed to accept (or
visual-info card29) for visual argument. This change should be made where
applicable in other CLX functions, so that visual-info can be used
consistently as the primary interface to visual types.
(defmacro colormap-visual (colormap)
"Access a visual-info structure on the colormap-plist."
`(getf (colormap-plist ,colormap) :visual))
(defun display-visual-info (display visual)
"Return a visual-info structure for the given VISUAL id."
(declare (type (or visual-info card29) visual)
(type display display))
(declare-values (or visual-info null))
(if (visual-info-p visual)
;; Return given visual-info.
visual
;; Else look up visual id among display screens
(block search
(dolist (screen (display-roots display))
;; Look up visual among screen depths
(dolist (depth (screen-depths screen))
(let ((visual-info (find visual (rest depth)
:key #'visual-info-id
:test #'eq)))
(when visual-info
(return-from search visual-info))))))))
(defun create-colormap (visual window &optional alloc-p)
(declare (type (or visual-info card29) visual)
(type window window)
(type boolean alloc-p))
(declare-values colormap)
(let* ((display (window-display window))
(colormap (make-colormap :display display))
(id (allocate-resource-id display colormap 'colormap)))
(setf (colormap-id colormap) id
(colormap-visual (display-visual-info display visual)))
(with-buffer-request (display *x-createcolormap*)
((data boolean) alloc-p)
(resource-id id)
(window window)
(card29 visual))
colormap))
∂26-Jul-89 0919 CL-Windows-mailer xlib:create-glyph-cursor -- a spec issue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89 09:19:36 PDT
Received: by ti.com id AA20753; Wed, 26 Jul 89 11:20:21 CDT
Received: from dsg by tilde id AA05057; Wed, 26 Jul 89 11:12:17 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 26 Jul 89 11:04:23 EDT
Message-Id: <2826454274-5194068@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 26 Jul 89 10:11:14 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: xlib:create-glyph-cursor -- a spec issue
In-Reply-To: Msg of Tue, 25 Jul 89 18:27:55 -0400 from rws@expo.lcs.mit.edu
I stumbled on a minor lacuna in the CLX spec for create-glyph-cursor. What is
supposed to happen when mask-font is specified but mask-char is omitted? The
code just wires mask-char=0, which doesn't seem particularly useful. Several
alternatives are possible.
1. Signal error
2. Default to source-char
3. Default to 0
4. Default to (font-default-char mask-font)
5. If (eq source-font mask-font), default to (1+ source-char), else signal
error.
I suggest #5. Since the source/mask-char's have to be tightly coupled, it's not
reasonable that any single value could serve as a default mask-char, so #2 is
plausible but #1 is more correct. But #5 also allows a short-hand for a common
idiom based on a special font structure (like that of the "cursor" font).
∂26-Jul-89 1346 CL-Windows-mailer xlib:create-glyph-cursor -- a spec issue
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 13:46:02 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632061; 26 Jul 89 16:47:47 EDT
Date: Wed, 26 Jul 89 16:47 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: xlib:create-glyph-cursor -- a spec issue
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2826454274-5194068@Sierra>
Message-ID: <19890726204745.0.MMCM@OWL.SCRC.Symbolics.COM>
Date: Wed, 26 Jul 89 10:11:14 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
I stumbled on a minor lacuna in the CLX spec for create-glyph-cursor. What is
supposed to happen when mask-font is specified but mask-char is omitted? The
code just wires mask-char=0, which doesn't seem particularly useful. Several
alternatives are possible.
1. Signal error
2. Default to source-char
3. Default to 0
4. Default to (font-default-char mask-font)
5. If (eq source-font mask-font), default to (1+ source-char), else signal
error.
I suggest #5. Since the source/mask-char's have to be tightly coupled, it's not
reasonable that any single value could serve as a default mask-char, so #2 is
plausible but #1 is more correct. But #5 also allows a short-hand for a common
idiom based on a special font structure (like that of the "cursor" font).
5 sounds reasonable, especially if mask-font defaults to source-font.
∂26-Jul-89 1434 CL-Windows-mailer Re: xlib:create-glyph-cursor -- a spec issue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:34:12 PDT
Received: by ti.com id AA23860; Wed, 26 Jul 89 16:35:06 CDT
Received: from dsg by tilde id AA13331; Wed, 26 Jul 89 16:18:33 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 26 Jul 89 16:10:23 EDT
Message-Id: <2826472632-6297018@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Wed, 26 Jul 89 15:17:12 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: cl-windows@sail.stanford.edu
Subject: Re: xlib:create-glyph-cursor -- a spec issue
In-Reply-To: Msg of Wed, 26 Jul 89 16:47 EDT from Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
> What is
> supposed to happen when mask-font is specified but mask-char is omitted? The
> code just wires mask-char=0, which doesn't seem particularly useful. Several
> alternatives are possible.
>
> 1. Signal error
>
> 2. Default to source-char
>
> 3. Default to 0
>
> 4. Default to (font-default-char mask-font)
>
> 5. If (eq source-font mask-font), default to (1+ source-char), else signal
> error.
>
> I suggest #5. Since the source/mask-char's have to be tightly coupled, it's not
> reasonable that any single value could serve as a default mask-char, so #2 is
> plausible but #1 is more correct. But #5 also allows a short-hand for a common
> idiom based on a special font structure (like that of the "cursor" font).
>
> 5 sounds reasonable, especially if mask-font defaults to source-font.
But it doesn't. Omitting mask-font means "no mask", i.e. "mask is all 1's".
∂26-Jul-89 1501 CL-Windows-mailer xlib:create-glyph-cursor -- a spec issue
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 15:01:07 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632165; 26 Jul 89 18:02:31 EDT
Date: Wed, 26 Jul 89 18:02 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: xlib:create-glyph-cursor -- a spec issue
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2826454274-5194068@Sierra>
Supersedes: <19890726204745.0.MMCM@OWL.SCRC.Symbolics.COM>
Comments: Correct misunderstanding.
Message-ID: <19890726220229.0.MMCM@OWL.SCRC.Symbolics.COM>
Date: Wed, 26 Jul 89 10:11:14 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
I stumbled on a minor lacuna in the CLX spec for create-glyph-cursor. What is
supposed to happen when mask-font is specified but mask-char is omitted? The
code just wires mask-char=0, which doesn't seem particularly useful. Several
alternatives are possible.
1. Signal error
2. Default to source-char
3. Default to 0
4. Default to (font-default-char mask-font)
5. If (eq source-font mask-font), default to (1+ source-char), else signal
error.
I suggest #5. Since the source/mask-char's have to be tightly coupled, it's not
reasonable that any single value could serve as a default mask-char, so #2 is
plausible but #1 is more correct. But #5 also allows a short-hand for a common
idiom based on a special font structure (like that of the "cursor" font).
5 sounds reasonable enough.
∂26-Jul-89 1503 CL-Windows-mailer Re: xlib:create-glyph-cursor -- a spec issue
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 15:02:58 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632171; 26 Jul 89 18:04:35 EDT
Date: Wed, 26 Jul 89 18:04 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: xlib:create-glyph-cursor -- a spec issue
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2826472632-6297018@Sierra>
Message-ID: <19890726220434.1.MMCM@OWL.SCRC.Symbolics.COM>
Date: Wed, 26 Jul 89 15:17:12 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
> What is
> supposed to happen when mask-font is specified but mask-char is omitted? The
> code just wires mask-char=0, which doesn't seem particularly useful. Several
> alternatives are possible.
>
> 1. Signal error
>
> 2. Default to source-char
>
> 3. Default to 0
>
> 4. Default to (font-default-char mask-font)
>
> 5. If (eq source-font mask-font), default to (1+ source-char), else signal
> error.
>
> I suggest #5. Since the source/mask-char's have to be tightly coupled, it's not
> reasonable that any single value could serve as a default mask-char, so #2 is
> plausible but #1 is more correct. But #5 also allows a short-hand for a common
> idiom based on a special font structure (like that of the "cursor" font).
>
> 5 sounds reasonable, especially if mask-font defaults to source-font.
But it doesn't. Omitting mask-font means "no mask", i.e. "mask is all 1's".
Right, as I noted in my follow-on message. It's still reasonable.
∂28-Jul-89 1028 CL-Windows-mailer too many contacts for clue 1-15??
Received: from lurch (lurch.cme.nist.gov) by SAIL.Stanford.EDU with TCP; 28 Jul 89 10:28:00 PDT
Received: by lurch (4.0/SMI-3.2-del.5)
id AA00705; Fri, 28 Jul 89 13:25:49 EDT
Date: Fri, 28 Jul 89 13:25:49 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8907281725.AA00705@lurch>
To: cl-windows@sail.stanford.edu
Subject: too many contacts for clue 1-15??
Hi we are running a program which is a tree editor of a sort.
Each node of trees to be edited is itself a contact.
When previously done in clue 1-13, it worked fine, however upon
switching to clue 1-15, the program would crash after some number of
nodes were created, or so it seemed. This effect could be created
by:
1) reading in a predefined tree of many nodes
2) reading a small (< 10 nodes) trees several times
3) creating ~100 nodes by hand.
This would crash the server.
My question is is there a limit to how many contacts may be mapped
in clue-1-15? The problem did not exist in clue-1-13, and to try and
deduce whether or not it was number of windows that caused the crash,
I wrote a program using CLX to create and map 1485 windows, this only slowed
the server down, so I would guess it is not the number of windows.
Is the problem a semi common one? We are using X11R3, R3 CLX, and
clue 1-15. Will specific patches to the server or CLue 6.0 solve this problem.
Forrest
NIST
∂28-Jul-89 1133 CL-Windows-mailer Re: too many contacts for clue 1-15??
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Jul 89 11:33:10 PDT
Received: by ti.com id AA12619; Fri, 28 Jul 89 13:34:04 CDT
Received: from dsg by tilde id AA06929; Fri, 28 Jul 89 13:21:25 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 28 Jul 89 13:14:08 EDT
Message-Id: <2826634833-16042299@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Fri, 28 Jul 89 12:20:33 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: chang@cme.nist.gov (Forrest Chang)
Cc: cl-windows@sail.stanford.edu
Subject: Re: too many contacts for clue 1-15??
In-Reply-To: Msg of Fri, 28 Jul 89 13:25:49 EDT from chang@cme.nist.gov (Forrest Chang)
> My question is is there a limit to how many contacts may be mapped
> in clue-1-15?
No. You say this crashes the server? Or just your client? In either case, I've
never heard of this one before.
If it's a server crash, you can use the CLX trace tool to try to find out which
request hit the wall. See clx/debug/trace.l.
∂28-Jul-89 1557 CL-Windows-mailer too many contacts, part II.
Received: from lurch (lurch.cme.nist.gov) by SAIL.Stanford.EDU with TCP; 28 Jul 89 15:56:57 PDT
Received: by lurch (4.0/SMI-3.2-del.5)
id AA00794; Fri, 28 Jul 89 17:51:55 EDT
Date: Fri, 28 Jul 89 17:51:55 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8907282151.AA00794@lurch>
To: Kimbrough@dsg.csc.ti.com, chang, cl-windows@sail.stanford.edu
Subject: too many contacts, part II.
Gentleman,
It seems further investigation of my "too many contacts" problem
narrows the cause but not the effect...
I recreated the CLX program for clue, i.e. a program that lets me
generate and map/present contacts. This one it seems will not let me make
more than 400 contacts, but this one seems to crash the client, and not
the server.
The number of contacts it allows me to create varies, apparently to
how fast they are created (I create them with key-presses). This is slightly
confusing.
The clx pgm, allows me to generate up to 1485 windows, the side
effect is slowing down the server (understandably).
The original program in question (a tree editor in which each node
is a contact) crashed the server when it read in a predefined tree of
some substatial size or several small trees. However, when I tried to isolate
the problem, by making nodes one at a time, it first locked up the client,
but when I killed it with xkill, the server crashed.
These problems were not present in the program with clue 1-13, and
appeared when we moved over to clue 1-15. Has the contact implementation
changed a fair amount between versions? The problem was origninal diagnosed
on a Sun 3/60 running X11R3, the recent testing has been on a sun2 running
X11r3.
Kerry Kimbrough has never seen this problem. Is there anyone else
out there with a similar problem. Can anyone else reproduce a crashing of the
client or server with the creation of, say, 400+ contacts.
Does anyone involved think clue 6.0 will help, or should we either
swithc back to 1-13 or, not use contacts for the nodes?
Forrest Chang
NIST
∂29-Jul-89 1500 CL-Windows-mailer Re: too many contacts, part II.
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 29 Jul 89 15:00:10 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Sat, 29 Jul 89 18:00:56 EDT
Received: by expire.lcs.mit.edu; Sat, 29 Jul 89 18:00:51 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8907292200.AA00317@expire.lcs.mit.edu>
To: chang@cme.nist.gov (Forrest Chang)
Cc: cl-windows@sail.stanford.edu
Subject: Re: too many contacts, part II.
In-Reply-To: Your message of Fri, 28 Jul 89 17:51:55 EDT.
<8907282151.AA00794@lurch>
Date: Sat, 29 Jul 89 18:00:50 -0400
Can anyone else reproduce a crashing of the
client or server with the creation of, say, 400+ contacts.
Are you using an R2-based server? It had a bug that would cause it to
crash when a client created lots of windows. If you're using an R3-based
server, and have a program that will crash the server, I'd like to see it.
∂02-Aug-89 1245 CL-Windows-mailer too many contacts? part III (longish)
Received: from rio.cme.nist.gov by SAIL.Stanford.EDU with TCP; 2 Aug 89 12:44:56 PDT
Received: by rio.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA02598; Wed, 2 Aug 89 15:45:07 EDT
Date: Wed, 2 Aug 89 15:45:07 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908021945.AA02598@rio.cme.nist.gov>
To: cl-windows@sail.stanford.edu
Subject: too many contacts? part III (longish)
Dear Sirs:
I am still semi clueless to what the problem is :
To sum it up, the tree editor (every node of the tree is a
contact) which worked fine with clue-1-13, does not run correctly with
clue1-15.
The original problem:
====================
Read in a large tree (creates and tries to map many nodes) and
the server crashes.
A server crash can also be reproduced with by loading several small
trees.
My initial inclination was that the problem might be related to the
number windows mapped.
I wrote a clx program that created and mapped a window for
every button-press. I generated up to 1485 windows at various speeds,
i.e. varying times between button-presses. This only slowed down the
server. Afterthought revealed that since the program worked fine with
clue-1-13, neither the server or clx _should_ be a fault.
So, I decided to reproduce the clx program using clue, mapping
contacts with every button press. After various it seemed that
"crashing the client" (apparently rendering the client insensitive to
input) was a function of how fast you create contacts
-- observed from one button-press maps one client. If you pressed the
button slow enough, you could create indefinite numbers of contacts.
Further experimentation, since traces did not provide any
seeable cause, just the usual jazz:
5112 MapWindow (8) length 8
5113 CreateWindow (1) length 44
5114 ChangeProperty (18) length 28
5115 MapSubwindows (9) length 8
5116 MapWindow (8) length 8
which looked for the most part correct, as far as I could
tell.
Experimentation with the number of clients created per
button-press revealed that I could create no more than 44 contacts at
one time. This number comes off of both the sun2 and sun3 X11R3
servers. A request for more than 44 contacts would result in the
mapping of 44 contacts, and the inablit to map contacts during the
life time of the program. Likewise two button-presses, each mapping
25 contacts, will yield the same result. So what was previously
misconstrued as crashing the client may have just been inability to
map contacts.
Is 44 a magic number for any one else? Why would this appear
in clue-1-15 and not in clue-1-13. How do I fix this, or better yet
what are some straws I can grasp at?
If someone can duplicate my "44 max contacts" problem, I could
know it's not just something peculiar to our stuff. I can send the
code that generated 44 as a max # if anyone's willing to try it out.
Note, I still cannot quite isolate what causes the X11R3
server to crash, but I assume the number of contacts has some hand in
this.
Thanx.
Forrest
NIST
∂03-Aug-89 1101 CL-Windows-mailer too many contacts? part IV, src
Received: from squire.cme.nist.gov by SAIL.Stanford.EDU with TCP; 3 Aug 89 11:01:04 PDT
Received: by squire.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA01514; Thu, 3 Aug 89 14:03:05 EDT
Date: Thu, 3 Aug 89 14:03:05 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908031803.AA01514@squire.cme.nist.gov>
To: cl-windows@sail.stanford.edu
Subject: too many contacts? part IV, src
To: Kerry Kimbrough, and anyone else willing to try it.
This is the program that results in the 44 contacts as a max number.
I originally mailed it to Kerry, but the mail all bounced.
original letter follows
!
----- Unsent message follows -----
Received: by tilde id AA17997; Thu, 3 Aug 89 10:34:17 CDT
Received: from squire.cme.nist.gov by ti.com id AA05300; Thu, 3 Aug 89 10:30:40 CDT
Received: by squire.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA00691; Thu, 3 Aug 89 11:31:35 EDT
Date: Thu, 3 Aug 89 11:31:35 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908031531.AA00691@squire.cme.nist.gov>
To: Kimbrough@csc.ti.com
Subject: the program
The contact making program is called clue-crash, the variable
*contact*, tells it how many windows to make per button-press.
You may want to try this with both clue 6.0 and clue-1-15.
Unfortunately,since we don't have clue-1-13 anymore, I can't see if I
get 44 as the max number for that (even tho' the original application
worked on that)
thanx much
Forrest
NIST
=======================
;;;-*- Mode: LISP; Syntax: Common-lisp; Package: clue-test; Base: 10 -*-
(in-package 'clue-test :use '(lisp clue))
(defvar *display*)
(defvar *trace* nil)
(defvar *contacts* 44)
(defvar *main*)
(defvar *debug* nil)
(defvar *white*)
(defvar *black*)
(defvar *gc*)
(defvar *x* 10)
(defvar *y* 10)
;;; PROLOGUE ================================================================
;;; Function Name: setup
;;; Author List: fkc
;;; Creation Date: lta
;;; Arguments: host
;;; Global Variables: none, but defines some..
;;; Description: does necessary X setup
;;;
;;; Return Value/Side Effects: below, globals are initialized
;;; ENDPROLOGUE ------------------------------------------------------------
(defun setup (host)
(when *debug* (format t "~%setup"))
(setf *x* 0)
(setf *y* 10)
(setq *display* (open-contact-display 'clue-crash :host host))
(when *trace* (xlib:trace-display *display*))
(print "open-display")
(setq *black* (xlib:screen-black-pixel
(xlib:display-default-screen *display*)))
(setq *white* (xlib:screen-white-pixel
(xlib:display-default-screen *display*)))
(setq *gc* (xlib:create-gcontext :drawable (display-root *display*)
:foreground *black*
:background *white*)))
;;; PROLOGUE ================================================================
;;; Function Name: quit
;;; Author List: fkc
;;; Creation Date: lta
;;; Arguments:
;;; Global Variables:
;;; Description: an action, usually to a button click, in this program
;;; that exits the program by throwing to the catch in the main lop
;;;
;;; Return Value/Side Effects: nil, exits program
;;; ENDPROLOGUE ------------------------------------------------------------
(defaction quit ((window composite))
(when *debug* (format t "~%action: quit"))
(throw 'loop-exit-catcher nil))
;;; PROLOGUE ================================================================
;;; Function Name: DO-THROW
;;; Author List: FKC, ORIGINALLY LAMOTT
;;; Creation Date: AVLTA
;;; Arguments: TAG VALUE
;;; Global Variables:
;;; Description: CAN'T USE A SPECIAL FORM -- THROW AS AN ACTION...
;;;
;;; Return Value/Side Effects: None
;;; ENDPROLOGUE ------------------------------------------------------------
(defun do-throw (tag value) (throw tag value))
;;; PROLOGUE ================================================================
;;; Function Name: MAKE-WINDOWS
;;; Author List: FKC
;;; Creation Date: LTA
;;; Arguments:
;;; Global Variables: *DISPLAY*, *MAIN*,
;;; Description: CREATES THE WINDOWS
;;;
;;; Return Value/Side Effects: None
;;; ENDPROLOGUE ------------------------------------------------------------
(defun make-windows ()
(when *debug* (format t "~%make-window2"))
(setq *main*
(make-contact 'composite :parent *display*
:name 'top-level-window
:border-width 2
:contact-background *white*
:height 720
:width 900
:x 100 :y 100
:border *black*
:event-translations '(
(:key-press make-new-contacts)
(:button-press quit))
:documentation "this is the top-level-window"))
)
(defaction make-new-contacts ((window composite))
(expose-line *contacts*))
(defun expose-line (i)
(cond ((> i 0)
(present (make-contact 'composite :parent *main2*
:name 'win
:border-width 2
:contact-background *white*
:height 20
:width 20
:x *x* :y *y*
:border *white*
:event-translations '()
:documentation "foo"))
(setf *x* (+ *x* 3))
(expose-line (- i 1)))
(t
(print "x change")
(setf *x* 0)
(setf *y* (+ *y* 25)))))
;;; PROLOGUE ================================================================
;;; Function Name: CLUE-CRASH
;;; Author List: FKC
;;; Creation Date: 28 july 89
;;; Arguments: OPTIONAL HOST
;;; Global Variables: *DISPLAY*
;;; Description: CREATES main and loops
;;; Return Value/Side Effects: None
;;; ENDPROLOGUE ------------------------------------------------------------
(defun clue-crash (&optional (host "plan"))
(when *debug* (format t "~%crash2"))
(setup host)
(process-all-events *display*)
(unwind-protect
(progn
(make-window2)
(present *main2*)
(catch 'loop-exit-catcher
(loop
(process-next-event *display*)
)))
(xlib:close-display *display*)))
∂04-Aug-89 1335 CL-Windows-mailer keycode->keysym bug
Received: from ti.com by SAIL.Stanford.EDU with TCP; 4 Aug 89 13:35:15 PDT
Received: by ti.com id AA17802; Fri, 4 Aug 89 15:35:56 CDT
Received: from dsg by tilde id AA22401; Fri, 4 Aug 89 15:17:25 CDT
Received: From RIGI By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 4 Aug 89 15:17:00 EDT
Message-Id: <2827253798-11662142@RIGI>
Sender: KK@RIGI.csc.ti.com
Date: Fri, 4 Aug 89 16:16:38 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu
Subject: keycode->keysym bug
VERSION:
R3
CLIENT MACHINE and OPERATING SYSTEM:
n/a
DISPLAY:
n/a
WINDOW MANAGER:
n/a
AREA:
CLX
SYNOPSIS:
Spec or code bug in keycode->keysym.
DESCRIPTION:
The spec says that keysym-index can be nil, but this will immediately cause
aref to choke. Who's wrong --- spec or code?
(defun keycode->keysym (display keycode keysym-index)
(declare (type display display)
(type card8 keycode)
(type (or null card8) keysym-index)
(values keysym))
FIX:
?
∂06-Aug-89 0612 CL-Windows-mailer Re: too many contacts? part IV, src
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 6 Aug 89 06:12:34 PDT
Received: from ai.leeds.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa02859; 6 Aug 89 14:00 BST
Via: cbl.leeds.ac.uk (esprit.ARPA); Sun, 6 Aug 89 14:10:19 GMT
From: R Williams <rodw%cbl.leeds.ac.uk@NSFnet-Relay.AC.UK>
Date: Sun, 6 Aug 89 14:14:15 BST
Message-Id: <10723.8908061314@cbl.leeds.ac.uk>
To: chang%cme.nist.gov@NSFnet-Relay.AC.UK, cl-windows@sail.stanford.edu
Subject: Re: too many contacts? part IV, src
Cc: clue-review%dsg.csc.ti.com@NSFnet-Relay.AC.UK
Hi,
The problem that you encountered was caused by the the automatic buffer
flushing in clx not padding out the request to the four byte boundary.
The following patch solves the problem. You will need to touch buffer.lisp
to make sure that it is re-compiled after the bufmac.lisp file has be altered.
There may also be a problem with the following files as very similar code is
used to flush the buffer in each case.
graphics.lisp
image.lisp
text.lisp
Rod
-------------------------cut here----------------------------------
*** bufmac.lisp Wed Jan 4 22:50:29 1989
--- ../CLX.altered/bufmac.lisp Sat Aug 5 18:08:36 1989
***************
*** 200,206 ****
;; Flush the buffer
(when (and (index-plusp len)
(index> buffer-boffset (buffer-limit buffer)))
! (setf (buffer-boffset buffer) buffer-boffset)
(buffer-flush buffer)
(setq buffer-boffset (buffer-boffset buffer))
#+clx-overlapping-arrays
--- 200,206 ----
;; Flush the buffer
(when (and (index-plusp len)
(index> buffer-boffset (buffer-limit buffer)))
! (setf (buffer-boffset buffer) (lround buffer-boffset))
(buffer-flush buffer)
(setq buffer-boffset (buffer-boffset buffer))
#+clx-overlapping-arrays
∂08-Aug-89 0733 CL-Windows-mailer keycode->keysym bug
Received: from ti.com ([128.247.159.133]) by SAIL.Stanford.EDU with TCP; 8 Aug 89 07:33:07 PDT
Received: by ti.com id AA08714; Mon, 7 Aug 89 10:47:47 CDT
Received: from stroke.csc.ti.com by tilde id AA28843; Mon, 7 Aug 89 10:39:09 CDT
Received: by stroke.csc.ti.com (4.0/SMI-4.0)
id AA02578; Mon, 7 Aug 89 10:38:59 CDT
Date: Mon, 7 Aug 89 10:38:59 CDT
From: oren@stroke.csc.ti.com (LaMott Oren)
Message-Id: <8908071538.AA02578@stroke.csc.ti.com>
To: Kimbrough@dsg.csc.ti.com
Cc: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu
In-Reply-To: Kerry Kimbrough's message of Fri, 4 Aug 89 16:16:38 EDT <2827253798-11662142@RIGI>
Subject: keycode->keysym bug
Sender: KK@rigi.csc.ti.com
Date: Fri, 4 Aug 89 16:16:38 EDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
The spec says that keysym-index can be nil, but this will immediately
cause aref to choke. Who's wrong --- spec or code?
(defun keycode->keysym (display keycode keysym-index)
(declare (type display display)
(type card8 keycode)
(type (or null card8) keysym-index)
(values keysym))
There are a lot of keycodes for which you can't unambiguously determine the
keysym from the keycode alone. I think keycode->keysym should take a state
argument like keycode->character:
(defun keycode->keysym (display keycode state &key keysym-index
(keysym-index-function #'default-keysym-index))
(declare (type display display)
(type card8 keycode)
(type card16 state)
(type (or null card8) keysym-index)
(type (or null (function (string-char card16 boolean card8) card8))
keysym-index-function))
(declare-values (or null keysym))
...)
∂08-Aug-89 1813 CL-Windows-mailer add me to your distribution list
Received: from KBESRL.ME.UIUC.EDU by SAIL.Stanford.EDU with TCP; 8 Aug 89 18:13:45 PDT
Date: 8 Aug 1989 20:14:27 EST
From: JIM.THOMPSON@KBESRL.ME.UIUC.EDU
To: cl-windows@sail.stanford.edu
Subject: add me to your distribution list
X-VMS-Original-To: INET%"cl-windows@sail.stanford.edu"
please add me (thompson@kbesrl.me.uiuc.edu) to your distribution list.
thanks.
jb thompson
knowledge-based engineering systems research laboratory
dept. of mechanical & industrial engineering
university of illinois at urbana-champaign
urbana, illinois
217-244-0292
∂14-Aug-89 1359 CL-Windows-mailer
Received: from squire.cme.nist.gov by SAIL.Stanford.EDU with TCP; 14 Aug 89 13:59:39 PDT
Received: by squire.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA15571; Mon, 14 Aug 89 17:01:33 EDT
Date: Mon, 14 Aug 89 17:01:33 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908142101.AA15571@squire.cme.nist.gov>
To: Kimbrough@ti.com, cl-windows@sail.stanford.edu
Subject: formerly too many contacts, now destroy???
Ok, after a good deal of tracking it down, I've found the
procedure that actually causes the server to crash.
=======================================
(defun clear-plan-display ()
(when *debug* (format t "~%alt-clear-plan-display"))
(with-slots (x y width height mouse-doc-window mouse-documentation)
(the scroll-window (get '*editor* 'plan-display-window))
; (destroy (get '*editor* 'plan-display-window))
(setf (get '*editor* 'plan-display-window)
(make-contact 'scroll-window :parent *editor* :name 'editor-plan-display-window
:x x :y y :width width :height height :state nil
:mouse-doc-window mouse-doc-window
:mouse-documentation mouse-documentation)))
(with-slots (x y width height mouse-doc-window mouse-documentation)
(the mirror-scroll-window (get '*editor* 'plan-mirror-window))
; (destroy (get '*editor* 'plan-mirror-window))
(setf(get '*editor* 'plan-mirror-window)
(make-contact 'mirror-scroll-window :parent *editor* :name 'editor-plan-mirror-window
:x x :y y :width width :height height :zoom *zoom*
:mirror-for (get '*editor* 'plan-display-window)
:state nil
:mouse-doc-window mouse-doc-window
:mouse-documentation mouse-documentation)))
(my-present (get '*editor* 'plan-display-window))
(my-present (get '*editor* 'plan-mirror-window))
(format t "~&exited clear-plan"))
==============
As far as I can figure out, is that the destroy command is what
causes the server to crash in some way. I've gone as far to comment
all code BUT the destroy commands, and it still crashes the server.
However, if you comment out the destroy commands, the program works
fine.
Unfortunately, I've tried to reproduce this in different
conditions by destroying windows in different conditions. But I
couldn't do it.
So, to deallocate the resoures, I did the following to fix
things, and it seems to work. Could you tell me if this is good/bad
or why it happened?
=================
(defun clear-plan-display ()
(let ((win1) (win2))
(format t "~&Entered clear-plan-display, baby 4.0")
(when *debug* (format t "~%alt-clear-plan-display"))
(with-slots (x y width height mouse-doc-window mouse-documentation)
(the scroll-window (get '*editor* 'plan-display-window))
(setf win1 (get '*editor* 'plan-display-window))
;; (destroy (get '*editor* 'plan-display-window))
(setf (get '*editor* 'plan-display-window)
(make-contact 'scroll-window :parent *editor* :name 'editor-plan-display-window
:x x :y y :width width :height height :state nil
:mouse-doc-window mouse-doc-window
:mouse-documentation mouse-documentation)))
(with-slots (x y width height mouse-doc-window mouse-documentation)
(the mirror-scroll-window (get '*editor* 'plan-mirror-window))
(setf win2 (get '*editor* 'plan-mirror-window))
;;; (destroy (get '*editor* 'plan-mirror-window))
(setf(get '*editor* 'plan-mirror-window)
(make-contact 'mirror-scroll-window :parent *editor* :name 'editor-plan-mirror-window
:x x :y y :width width :height height :zoom *zoom*
:mirror-for (get '*editor* 'plan-display-window)
:state nil
:mouse-doc-window mouse-doc-window
:mouse-documentation mouse-documentation)))
(my-present (get '*editor* 'plan-display-window))
(my-present (get '*editor* 'plan-mirror-window))
(destroy win1)
(destroy win2)
(format t "~&exited clear-plan"))
)
===========
I'll add that the original code worked with clue-1-13. Has
destroyed changed in a way that would change this, is it the same in
clue 6.0? We used the method of destroying a window and resetting it to a new
contact as a way to clear a window with many nodes so we could read in a new
plan.
Thanx for your help
Forrest
NIST
∂15-Aug-89 0004 CL-Windows-mailer The Joy of Window-Override-Redirect
Received: from PROOF.ERGO.CS.CMU.EDU ([128.2.222.187]) by SAIL.Stanford.EDU with TCP; 15 Aug 89 00:04:23 PDT
Received: from PROOF.ERGO.CS.CMU.EDU by PROOF.ERGO.CS.CMU.EDU; 15 Aug 89 03:04:12 EDT
To: cl-windows@sail.stanford.edu
Reply-to: Tim Freeman <tsf@cs.cmu.edu>
Subject: The Joy of Window-Override-Redirect
Date: Tue, 15 Aug 89 03:04:11 EDT
Message-ID: <12283.619167851@PROOF.ERGO.CS.CMU.EDU>
From: Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU
Here's a nead hack. I didn't see uses of this in the Clue code I
recently fetched from csc.ti.com, so maybe someone out there will have
a use for this.
I just figured out what window-override-redirect is good for. You
have to use it if you want to correctly cache the width and height of
windows on the client side of the connection. Before my application
did this, I found that it was spending most of its time running back
and forth to the server getting the widths and heights of windows.
Here's comment I inserted into my code to explain things.
;;; X11 resize wonders:
;;; We have to keep the shape of the window cached in the window
;;; somewhere, because we ask for the shape of the window very often,
;;; and if there's a round trip to the server for each request, we
;;; spend most of the time figuring out the sizes of our windows.
;;;
;;; So we do the obvious thing: when we resize our windows, we stash
;;; the new width and height in instance variables, and redefine
;;; drawable-width &co to deal with these instance variables. The
;;; class optimize-drawable-width-height deals with this.
;;;
;;; The problem comes when the window manager can resize our top level
;;; windows. We ought to get an event that says to update the stashed
;;; width and height. There isn't normally an event that means "Someone else
;;; resized your window"; the choices are to receive configure-notify
;;; events or to play with resize-redirects.
;;;
;;; Receiving configure-notifies is analogous to what we did in X10.
;;; The problem is that we will receive configure-notifies for any
;;; resize of the window, whether we decided to do the resize or the
;;; window manager decided to do the resize. By keeping track of our
;;; own resizes, is possible to correctly guess most of the time which
;;; resizes are due to our behavior and which are due to the window
;;; managers, but the code was a pain to write and is ugly (see div.lisp).
;;; It was even worse under x10, since both resizes and exposures
;;; looked like exposure events.
;;;
;;; So, the ideal solution is to turn on resize-redirect on each
;;; window. Resize-redirect allows this process to resize its own
;;; windows without any problems, but when the window manager resizes
;;; a window, the only thing that happens is we get a resize-request
;;; event. So, when we get a resize-request event, we should resize
;;; the window to whatever the window manager wants, and update our
;;; idea of the shape of the window appropriately.
;;;
;;; This almost works. The bug is that when we resize the window the
;;; way the WM wants, the WM sees our resizing, and then it tries to
;;; fit the window to our resizing by resizing the frame that has the
;;; title bar. This has the side effect of resizing our window to the
;;; size it already is, and then we get a resize-request, and we
;;; resize our window, ... and we loop.
;;;
;;; So, the trick is for us to do our resize without the WM noticing.
;;; Before the resize, we set window-override-redirect for the window
;;; to :on, and after our resize, we set it to :off. This works.
∂15-Aug-89 0440 CL-Windows-mailer Re: The Joy of Window-Override-Redirect
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 15 Aug 89 04:39:59 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Tue, 15 Aug 89 07:40:51 EDT
Received: by expire.lcs.mit.edu; Tue, 15 Aug 89 07:40:45 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8908151140.AA01599@expire.lcs.mit.edu>
To: Tim Freeman <tsf@cs.cmu.edu>
Cc: cl-windows@sail.stanford.edu
Subject: Re: The Joy of Window-Override-Redirect
In-Reply-To: Your message of Tue, 15 Aug 89 03:04:11 EDT.
<12283.619167851@PROOF.ERGO.CS.CMU.EDU>
Date: Tue, 15 Aug 89 07:40:44 -0400
So, the trick is for us to do our resize without the WM noticing.
Before the resize, we set window-override-redirect for the window
to :on, and after our resize, we set it to :off. This works.
This is stated as a Convention in Section 4.2.9 of the ICCCM.
∂15-Aug-89 1315 CL-Windows-mailer
Received: from squire.cme.nist.gov by SAIL.Stanford.EDU with TCP; 15 Aug 89 13:14:36 PDT
Received: by squire.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA02480; Tue, 15 Aug 89 16:16:57 EDT
Date: Tue, 15 Aug 89 16:16:57 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908152016.AA02480@squire.cme.nist.gov>
To: cl-windows@sail.stanford.edu
Subject: destroy? Formerly too many contacts.
To Kerry Kimbrough, and anyone else interested. Sorry but my mail
to these addresses: dsg.csc.ti.com, ti.com,
csc.ti.com, all bounce. Anyone got another address to Kerry?
!
I used to the trace utilities when you first suggested them a ways
back, along with trying to debug the core dump, but they really couldn't
point out anything really.
Here is a clip from the trace:
============================
EVENT BUTTON-RELEASE (5) Sequence 722
727 UnmapWindow (10) length 8
728 PolyFillRectangle (70) length 20
729 PolyText8 (74) length 28
730 ClearToBackground (61) length 16
731 PolyText8 (74) length 36
732 ClearToBackground (61) length 16
733 PolyText8 (74) length 52
734 ChangeWindowAttributes (2) length 16
735 DestroyWindow (4) length 8
736 ChangeWindowAttributes (2) length 16
737 DestroyWindow (4) length 8
738 CreateWindow (1) length 48
739 MapSubwindows (9) length 8
740 MapWindow (8) length 8
741 CreateWindow (1) length 48
742 GetWindowAttributes (3) length 8
EVENT UNMAP-NOTIFY (18) Sequence 727
--More--
EVENT EXPOSURE (12) Sequence 727
EVENT EXPOSURE (12) Sequence 727
EVENT LEAVE-NOTIFY (8) Sequence 727
EVENT LEAVE-NOTIFY (8) Sequence 727
EVENT ENTER-NOTIFY (7) Sequence 727
NIL
Command:
=============================================
The actual server commands to DestroyWindow are #'s 735 and 737,
I'd assume these correspond to the clue:destroy commands in the code I sent
last time. However there is a good deal of action, 5 request and 6 events
before the server actually crashes. The last request is for a
GetWindowAttributes, and I can't see how that crashes it.
Seeking further enlightenment, I looked at a description of this
history, enclosed:
=============================================
(xlib:describe-trace clue::*display* 10)
739 MapSubwindows (9) length 8
0 99OPCODE
1 84XUNUSED
2 22REQUEST-LENGTH
4 7340282 [#x7000FA]WINDOWWINDOW
740 MapWindow (8) length 8
0 88OPCODE
1 0XUNUSED
2 22REQUEST-LENGTH
4 7340282 [#x7000FA]WINDOWWINDOW
741 CreateWindow (1) length 48
0 11OPCODE
1 1CARD8DEPTH
2 128+NREQUEST-LENGTH
4 7340283 [#x7000FB]WINDOWWID
8 7340134 [#x700066]WINDOWPARENT
12 806INT16X
14 53INT16Y
16 294CARD16WIDTH
18 282CARD16HEIGHT
20 1CARD16BORDER-WIDTH
22 0 COPYFROMPARENTMEMBERCLASS
24 0(OR (MEMBER COPYFROMPARENT)
VISUALID) VISUAL
28 18497 (BACKGROUND-PIXMAP BACKING-STORE EVENT-MASK CURSOR)BITMASK !
VALUE-MASK
32 LISTOFVALUE VALUE-LIST Words:
1 1 32820 7340041
742 GetWindowAttributes (3) length 8
0 33OPCODE
1 0XUNUSED
2 22REQUEST-LENGTH
4 7340283 [#x7000FB]WINDOWWINDOW
EVENT from 727 :EVENT-KEY :UNMAP-NOTIFY :SEQUENCE 727 :EVENT-WINDOW #<COMPOSIT!
E UNNAMED 304077004> :WINDOW #<COMPOSITE UNNAMED 304077004> :CONFIGURE-P NIL
EVENT from 727 :EVENT-KEY :EXPOSURE :SEQUENCE 727 :WINDOW #<MENU-BUTTON DELETE!
PLAN 304035737> :EVENT-WINDOW #<MENU-BUTTON DELETEPLAN 304035737> :X 42 :Y 0 :W!
IDTH 67 :HEIGHT 4 :COUNT 0
EVENT from 727 :EVENT-KEY :EXPOSURE :SEQUENCE 727 :WINDOW #<MENU-BUTTON EDITPL!
AN 304035451> :EVENT-WINDOW #<MENU-BUTTON EDITPLAN 304035451> :X 42 :Y 15 :WIDT!
H 67 :HEIGHT 33 :COUNT 0
EVENT from 727 :EVENT-KEY :LEAVE-NOTIFY :KIND :NONLINEAR :SEQUENCE 727 :TIME 4!
061673612 :ROOT #<WINDOW 304023500> :WINDOW #<MENU-BUTTON PLAN1.1 304077035> :E!
VENT-WINDOW #<MENU-BUTTON PLAN1.1 304077035> :CHILD NIL :ROOT-X 1057 :ROOT-Y 44!
5 :X 33 :Y 8 :STATE 0 :MODE :NORMAL :FOCUS-P T :SAME-SCREEN-P T
EVENT from 727 :EVENT-KEY :LEAVE-NOTIFY :KIND :NONLINEAR-VIRTUAL :SEQUENCE 727!
:TIME 4061673612 :ROOT #<WINDOW 304023500> :WINDOW #<COMPOSITE UNNAMED 3040770!
04> :EVENT-WINDOW #<COMPOSITE UNNAMED 304077004> :CHILD NIL :ROOT-X 1057 :ROOT-!
Y 445 :X 33 :Y 8 :STATE 0 :MODE :NORMAL :FOCUS-P T :SAME-SCREEN-P T
EVENT from 727 :EVENT-KEY :ENTER-NOTIFY :KIND :NONLINEAR :SEQUENCE 727 :TIME 4!
061673612 :ROOT #<WINDOW 304023500> :WINDOW #<MENU-BUTTON EDITPLAN 304035451> :!
EVENT-WINDOW #<MENU-BUTTON EDITPLAN 304035451> :CHILD NIL :ROOT-X 1057 :ROOT-Y !
445 :X 77 :Y 25 :STATE 0 :MODE :NORMAL :FOCUS-P T :SAME-SCREEN-P T
NIL
Command:
==========================
In truth, this didn't tell ME very much.
Also, one of the first things I did was to look at the core dump
to get an idea of the problem, it looked like this:
==========================
(dbx) where
sunSaveAreas(0x12fe80) at 0x4614
DoObscures(0x12fe80) at 0x37c67
DoObscures(0x12f2f8) at 0x37c95
UnmapWindow(0x12fe80, 0x1, 0x1, 0x0) at 0x3c085
DeleteWindow(0x12fe80, 0x30006b) at 0x38d27
FreeResource(0x30006b, 0x1) at 0x30e73
ProcDestroyWindow(0x14c5f8) at 0x20e9b
SProcResourceReq(0x14c5f8) at 0x355db
Dispatch() at 0x20bbf
main(0x2, 0xfffdec, 0xfffdf8) at 0x2f565
(dbx)
==========================
The last command is sunSaveAreas, this is some kinda cursor thing..
Couldn't figure out why it crashed...
ANY hints or ideas, I need a direction. I don't feel right just
treating the symptoms, like I did, and I want to find the source of the problem
Thanx
Forrest
NIST
∂15-Aug-89 1336 CL-Windows-mailer server crash
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 15 Aug 89 13:36:37 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Tue, 15 Aug 89 16:37:25 EDT
Received: by expire.lcs.mit.edu; Tue, 15 Aug 89 16:37:22 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8908152037.AA04054@expire.lcs.mit.edu>
To: chang@cme.nist.gov (Forrest Chang)
Cc: cl-windows@sail.stanford.edu
Subject: server crash
In-Reply-To: Your message of Tue, 15 Aug 89 16:16:57 EDT.
<8908152016.AA02480@squire.cme.nist.gov>
Date: Tue, 15 Aug 89 16:37:20 -0400
ANY hints or ideas, I need a direction.
Do you have all of the public fixes installed? This sounds suspiciously
like a server crash problem that was corrected in fix #8.
∂17-Aug-89 1834 CL-Windows-mailer Need help with image/pixmap problem
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 17 Aug 89 18:33:34 PDT
Received: from vax9.cs.umass.edu by crash.cs.umass.edu (5.61/Ultrix2.0-B)
id AA05663; Thu, 17 Aug 89 21:38:50 -0400
Message-Id: <8908180138.AA05663@crash.cs.umass.edu>
Date: Thu, 17 Aug 89 21:35 EST
From: BROLIO@cs.umass.EDU
Subject: Need help with image/pixmap problem
To: cl-windows@sail.stanford.EDU
X-Vms-To: LISP-X
HELP. I am having a problem with images and pixmaps. I must be doing
something wrong. CLX keeps wanting to pad my image with zero words, and
I don't know why. What happens is that I make an image from a C Bitmap
file (works fine in C). If I use read-bitmap-from-file, my image (in
this case all 1's) becomes padded with two bytes of 0's every other 2
bytes.
If I use a different form with create-image, everything looks innocent
until I put-image the image in the pixmap. Then the zero word padding
starts again.
Sure looks funny on the screen. Anyone got a clue???
Below is the example. I'm running CLX on a TI Explorer, using
a Vaxstation 2000 as the Xserver and display (X11 R3).
John Brolio
Brolio@cs.umass.edu
GBB Development Group
(413) 545-3279
----------- The C bitmap file --------------------------
#define horiz_width 16
#define horiz_height 16
#define horiz_x_hot 7
#define horiz_y_hot 8
static char horiz_bits[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
---------------------------------------------------------
The Code
(setf pix (read-bitmap-from-file "horiz.c"))
'#S(IMAGE-X :WIDTH 16 :HEIGHT 16 :PLIST (:NAME :HORIZ :Y_HOT 8 :X_HOT 7 :HEIGHT 16 :WIDTH 16)
:FORMAT :XY-PIXMAP :BYTES-PER-LINE 4 :BIT-LSB-FIRST-P T
:DATA #(255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0
255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255
0 0 255 255 0 0 255 255 0 0 255 255 0 0))
;;; -----------------------------------------------------------------
;; NOTE THAT THERE ARE LINES OF ZEROES EVERY TWO BYTES NOW.
;;; -----------------------------------------------------------------
(setf map (create-pixmap :width 16 :height 16 :depth 1 :drawable *root*))
(put-image map gc pix :x 0 :y 0 :width 16 :height 16 :bitmap-p t)
'#S(IMAGE-X :WIDTH 16 :HEIGHT 16 :PLIST (:NAME :HORIZ :Y_HOT 8 :X_HOT 7 :HEIGHT 16 :WIDTH 16)
:FORMAT :XY-PIXMAP :BYTES-PER-LINE 4 :BIT-LSB-FIRST-P T :BYTE-LSB-FIRST-P T
:DATA #(0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255
0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0
255 255 0 0 255 255 0 0 255 255 0 0 255 255))
;;; -----------------------------------------------------------------
;; NOTE THAT THE ORDER HAS BEEN ROTATED TWO BYTES
;;; -----------------------------------------------------------------
****** another version
;;; THE FILE
(defconstant %horiz-width% 16)
(defconstant %horiz-height% 16)
(defconstant %horiz-x-hot% 7)
(defconstant %horiz-y-hot% 8)
(defconstant %horiz-bits% #(
#xff #xff #xff #xff #xff #xff #xff #xff #xff #xff #xff #xff
#xff #xff #xff #xff #xff #xff #xff #xff #xff #xff #xff #xff
#xff #xff #xff #xff #xff #xff #xff #xff ))
;;; =================================================================
(setf im (xlib::create-image :depth 1 :data %horiz-bits%
:x-hot %horiz-x-hot% :y-hot %horiz-y-hot%
:width %horiz-width% :height %horiz-height%))
#S(XLIB:IMAGE-X :WIDTH 16 :HEIGHT 16 :PLIST (:Y_HOT 8 :X_HOT 7) :FORMAT :XY-PIXMAP
:BYTES-PER-LINE 2
:DATA #(255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255 255 255 255))
(put-image map gc pix :x 0 :y 0 :width 16 :height 16 :bitmap-p t)
#S(XLIB:IMAGE-X :WIDTH 16 :HEIGHT 16 :PLIST (:Y_HOT 8 :X_HOT 7) :FORMAT :XY-PIXMAP
:BYTES-PER-LINE 2 :BIT-LSB-FIRST-P T :BYTE-LSB-FIRST-P T
:DATA #(0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0
255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255
0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255))
;;; -----------------------------------------------------------------
;;; NOTE THAT "PUTTING" THE IMAGE ADDS THE TWO BYTES OF ZEROES.
;;; -----------------------------------------------------------------
∂22-Aug-89 1330 CL-Windows-mailer call for participation in the 4th Annual X Technical Conference
Received: from expo.lcs.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 13:30:51 PDT
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Tue, 22 Aug 89 16:31:42 EDT
Received: by expire.lcs.mit.edu; Tue, 22 Aug 89 16:31:40 EDT
From: rws@expo.lcs.mit.edu
Message-Id: <8908222031.AA00736@expire.lcs.mit.edu>
To: cl-windows@sail.stanford.edu
Subject: call for participation in the 4th Annual X Technical Conference
Date: Tue, 22 Aug 89 16:31:39 -0400
CALL FOR PARTICIPATION
in the
4TH ANNUAL X TECHNICAL CONFERENCE
The 4th annual Technical Conference on the X Window System will be held on
January 15-17, 1990 at the Marriott Copley Place Hotel in Boston, MA. The
conference, sponsored by the MIT X Consortium, will bring together experts from
industry and academia to present and discuss leading edge research and
development in the X environment. This is an ideal opportunity to learn about
the very latest X technology, and to talk individually with a variety of
developers.
As with last year, there will be tutorials on the first day. If you are
interested in giving a tutorial, please contact us. We are particularly
interested in topics which have not been given before, or which have had only
limited attendance. Tutorials on commerical products are allowed, although we
reserve the right to have the material "(un)slanted" appropriately for the
conference.
The second two days will be devoted to talks, in a single track. Presentations
can be anywhere from 5 to 50 minutes, and video tape is welcome. Written
papers are welcome, but not required; but, we would like to reproduce any
slides and written materials in advance for distribution at the conference.
There is no set "theme" for the conference; we are interested in submissions
covering all aspects of X. Presentations on both research and commercial
developments are welcome.
On all three days, there will be "Birds of a Feather" sessions for general
discussion of areas of specific interest to the attendees. If there are
particular BOFs you would like to see or run, please let us know.
As usual, there will no "trade show" attached to this conference.
If you would like to give a tutorial, make a presentation, or run a BOF,
send details to:
xconference@expo.lcs.mit.edu
or
Bob Scheifler
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
Network mail is preferred. Please include your name, net and postal address,
phone number, affiliation, a reasonably detailed outline of what you want to
present, what your relationship is to the work (e.g. project manager, principal
designer, lead engineer, me-myself-and-I), how much time you need, and what A/V
facilities you need. The deadline for submissions is November 17; receipt will
be acknowledged. However, we will not wait for this deadline before making
decisions on tutorials, so the earlier you get your tutorial proposal in, the
better your chances are.
If you are interested in serving (electronically) on the program committee
for this conference, please send mail by September 22 to:
xconference@expo.lcs.mit.edu
Due to the costs of holding the conference off campus (we've outgrown MIT's
facilities), there will be a registration fee of $50, covering the entire
conference (this is not to make a profit, but to keep the X Consortium subsidy
within reason). Exceptions will be made for students who cannot afford the
fee.
Since there will be a fee this year, registration will not be handled by
electronic mail. Please do *not* send inquiries about registration yet; we'll
send out registration and hotel information a little later. However, if you
believe your network mail is unreliable and are concerned that you might not
see later announcements in this forum, you can be placed on a mailing list to
receive information by post by writing to:
X Technical Conference
c/o MIT Conference Services
Room 7-111
77 Massachusetts Ave
Cambridge, MA 02139
∂25-Aug-89 1730 CL-Windows-mailer store-color in CLX version 4
Received: from PROOF.ERGO.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:29:51 PDT
Received: from PROOF.ERGO.CS.CMU.EDU by PROOF.ERGO.CS.CMU.EDU; 25 Aug 89 20:30:10 EDT
Reply-to: Tim Freeman <tsf@cs.cmu.edu>
To: cl-windows@sail.stanford.EDU, bug-clx@expo.lcs.mit.edu
subject: store-color in CLX version 4
Date: Fri, 25 Aug 89 20:30:08 EDT
Message-ID: <9326.620094608@PROOF.ERGO.CS.CMU.EDU>
From: Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU
I noticed a bug in store-color. In the branch that makes the call to
storenamedcolor, the flags are ignored.
The file clx.lisp claims that I'm using CLX version 4.
Is there somewhere I can get all the CLX patches? I'd be surprised if
this hasn't been noticed and fixed by someone else yet.
I haven't managed to draw a green line across a window yet, and I
don't know if I'm being numb-brained about colormaps or there's some
bug in the server or there's some bug in CLX. I could do all this in
X10. On a pseudo-color screen with max-installed-colormaps set to 1,
are you supposed to manipulate the colormap of the root window, or are
you supposed to create your own colormap? If I try to manipulate the
colormap of the root window, there cells I allocate aren't
automatically freed when my program exits. If I create my own
colormap, then the first pixel allocated is number 0, I get access
errors when I try to store something in that cell of the colormap.
In the file requests.lisp:
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type pixel pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p))
(let ((display (colormap-display colormap))
(flags 0))
(declare (type display display)
(type card8 flags))
(when red-p (setq flags 1))
(when green-p (incf flags 2))
(when blue-p (incf flags 4))
(with-display (display)
(etypecase spec
(color
(with-buffer-request (display *x-storecolors*)
(colormap colormap)
(card32 pixel)
(rgb-val (color-red spec)
(color-green spec)
(color-blue spec))
(card8 flags)
(pad8 nil)))
(stringable
(let* ((string (string spec))
(length (length string)))
(with-buffer-request (display *x-storenamedcolor*)
((data card8) flags) ; <<< ----- This line added
(colormap colormap)
(card32 pixel)
(card16 length)
(pad16 nil)
(string string))))
))))
∂31-Aug-89 1212 CL-Windows-mailer
Received: from squire.cme.nist.gov ([129.6.32.19]) by SAIL.Stanford.EDU with TCP; 31 Aug 89 12:11:54 PDT
Received: by squire.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA11841; Thu, 31 Aug 89 15:14:30 EDT
Date: Thu, 31 Aug 89 15:14:30 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8908311914.AA11841@squire.cme.nist.gov>
To: cl-windows@sail.stanford.edu
Subject: Paging and performance.
Has anyone running CLUE on a symbolics suffered a paging/performance
problem between applications written in clue 1-13 and clue 1-15. We are
metering the application to try to narrow down the culprit. Unfortunately,
each metering run takes about 2 hours so we have only 4 sets of data in which
there are two pairs of data that are similar, but unlike the other pair.
Alot of thrashing seems to concetrated in calls that handle
events. The application in quesiton is the same tree editor that has
be mentioned before, the performance problem occurs when we try to
draw the tree (i.e. making and mapping all these contacts as nodes).
Apparently (which I've found is often very misleading) make and map
lots of contacts == thrashing about. Sound familiar to anyone?
In addition I will be bringing up clue 6.0 sometime soon, maybe
that will help.
Thanx for any help
Forrest
NIST
∂05-Sep-89 1210 CL-Windows-mailer silica
Received: from arpa.att.com by SAIL.Stanford.EDU with TCP; 5 Sep 89 12:10:15 PDT
From: allegra!tk@research.att.com
Date: Tue, 5 Sep 89 11:19:14 EDT
>From: tk@allegra (Thomas Kirk)
To: cl-windows@sail.stanford.edu
Subject: silica
Can anyone share any information about the Silica window system technology
from PARC, or perhaps references to papers or reports describing it?
thanks.
tom kirk
tk@allegra.att.com
∂06-Sep-89 1128 CL-Windows-mailer Re: Silica
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 89 11:27:21 PDT
Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA12526; Wed, 6 Sep 89 11:22:51 -0700
Received: by layla.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA01216; Wed, 6 Sep 89 11:25:58 PDT
Message-Id: <8909061825.AA01216@layla.parc.xerox.com>
Date: Wed, 6 Sep 89 11:25:58 PDT
From: <rao@parc.xerox.com>
To: cl-windows@sail.stanford.edu
Cc: tk%allegra.uucp@research.att.com
In-Reply-To: <890905-161444-2245@Xerox>
Subject: Re: Silica
Silica is a CLOS-based kernel for managing hierarchies of interactive regions.
Interactive regions are somewhat more general than the "lightweight" windows of
systems like X or NeWS. These interactive regions plus associated machinery
provide an object-oriented framework that allows uniform treatment of window
objects like those in X or NeWS, light weight gadgets typical of toolkit
layers, and even, structured graphics and application level nested objects.
Silica has been licensed by Xerox to International Lisp Associates (ILA) for
inclusion in the Common Lisp Interface Manager (CLIM). In addition, Silica is
the user interface programming substrate for a CommonLisp programming
environment currently being development by Franz, MCC, and Xerox.
The current implementation of Silica rests on two underlying platforms: a
Common Lisp (w/CLOS) platform and a display server (though technically a
display server could be just a graphics package, all current ports are to full
blown window systems). It currently runs on Franz Common Lisp, KCL, Lucid Lisp,
Symbolics Lisp, and Xerox Lisp using the X window system via CLX. It has also
in the past run on Xerox Lisp using the Interlisp-D window system. ILA has
done an initial port to the Symbolics window system, and will also do ports to
Allegro Common Lisp for the Macintosh and CLOE-86.
The essence of Silica's approach is to separate functionality from an
underlying unifying data structure, which in Silica's case is the hierarchy of
nested interactive regions. Functionality is treated as separate objects that
are attached to the interactive region tree (though special CLOS techniques are
used to avoid creating lots of separate objects and dumb forwarding methods) .
In particular, three broad areas of functionality are defined: 1) input - how
events are parsed and delivered to users of interactive regions, 2) output -
how a client performs output operation on space associated with a interactive
region, and 3) nesting - how the space associated with a parent region is
divided among its children and how repaints and input distribution are handled
within that level of the tree.
This separation of functionality from the underlying heirarchy allows
functionality to vary across the expanse of hierarchy and to be dynamically
selected. So appropriate functionality can be chosen based on the requirements
of the client. For example, at the desktop level, you may use a weighty
nesting contract (e.g. something functionally equivalent to X's window model)
whereas deeper in the tree you may use lighter toolkit contracts (e.g.
bordering).
ILA and I are currently working on technical specifications of Silica and CLIM.
If you are interested in recieving a copy of these specs for review, or if you
are interested in technical working papers on Silica, please send me your
electronic and physical mailing addresses. Indicate whether you want papers,
specs, or both.
Ramana Rao (Internet: Rao@parc.xerox.com)
Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road; Palo Alto, CA, USA 94304
TEL: 415-494-4716; FAX: 415-494-4334
∂06-Sep-89 1436 CL-Windows-mailer Re: Silica
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 89 14:36:50 PDT
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by LISP-PMAX1.SLISP.CS.CMU.EDU; 6 Sep 89 17:36:55 EDT
To: <rao@parc.xerox.com>
Reply-To: Christopher.Hoover@CS.CMU.EDU
cc: cl-windows@sail.stanford.edu, tk%allegra.uucp@research.att.com
Subject: Re: Silica
In-reply-to: Your message of Wed, 06 Sep 89 11:25:58 -0700.
<8909061825.AA01216@layla.parc.xerox.com>
Date: Wed, 06 Sep 89 17:36:51 EDT
Message-ID: <13028.621121011@LISP-PMAX1.SLISP.CS.CMU.EDU>
From: Christopher.Hoover@SPICE.CS.CMU.EDU
I'd like a copy of both the technical specs and the technical working papers on
Silica and CLIM.
Thank you,
Christopher Hoover
(Christopher.Hoover@CS.CMU.EDU)
5719 Elwood St. #12
Pittsburgh, PA 15232
∂11-Sep-89 1513 CL-Windows-mailer Re: store-color in CLX version 4
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 11 Sep 89 15:13:30 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA29532; Mon, 11 Sep 89 18:14:18 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA23584; Mon, 11 Sep 89 14:59:21 PDT
Received: by sparky.Franz.COM (4.0/FI-1.0)
id AA01334; Mon, 11 Sep 89 14:53:36 PDT
Message-Id: <8909112153.AA01334@sparky.Franz.COM>
To: Tim Freeman <ucbvax!ucbarpa!cs.cmu.edu!tsf@Franz.COM>
Cc: cl-windows@sail.stanford.edu, bug-clx@expo.lcs.mit.edu
Subject: Re: store-color in CLX version 4
In-Reply-To: Your message of Fri, 25 Aug 89 20:30:08 -0400.
<9326.620094608@PROOF.ERGO.CS.CMU.EDU>
Date: Mon, 11 Sep 89 14:53:35 -0700
From: John Irwin <jdi@Franz.COM>
Your message:
I noticed a bug in store-color. In the branch that makes the call to
storenamedcolor, the flags are ignored.
The file clx.lisp claims that I'm using CLX version 4.
Is there somewhere I can get all the CLX patches? I'd be surprised if
this hasn't been noticed and fixed by someone else yet.
The newest CLX is available via ftp from ucbarpa.berkeley.edu. Unfortunately
it is a few months old.
Fortunately I am about ready to make another distribution (which will also
be on ucbarpa, or possibly ucbvax, I will announce where and when).
It will include your fix. Go ahead and be surprised,
you were the first person to find it. :-)
-- John
∂25-Sep-89 1205 CL-Windows-mailer scroll windows in clue.
Received: from puertorico.cme.nist.gov by SAIL.Stanford.EDU with TCP; 25 Sep 89 12:05:47 PDT
Received: by puertorico.cme.nist.gov (4.0/SMI-3.2-del.5)
id AA07640; Mon, 25 Sep 89 15:01:42 EDT
Date: Mon, 25 Sep 89 15:01:42 EDT
From: chang@cme.nist.gov (Forrest Chang)
Message-Id: <8909251901.AA07640@puertorico.cme.nist.gov>
To: cl-windows@sail.stanford.edu
Subject: scroll windows in clue.
Has anyone written a scroll window contact in clue. I'm about
to start, but if someone else has already done it...
Thanx
Forrest
NIST
∂25-Sep-89 1705 CL-Windows-mailer New CLUE available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Sep 89 17:05:51 PDT
Received: by ti.com id AA29493; Mon, 25 Sep 89 19:06:35 CDT
Received: from dsg by tilde id AA07857; Mon, 25 Sep 89 18:57:28 CDT
Received: From RIGI By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Sep 89 18:56:37 CDT
Message-Id: <2831759787-1942667@RIGI>
Sender: KK@RIGI.csc.ti.com
Date: Mon, 25 Sep 89 18:56:27 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
xpert@expo.lcs.mit.edu
Subject: New CLUE available
CLUE 7.0 is now available to the public via anonymous ftp. This is
substantially the same as the previous version (CLUE 6.0, July 1989),
except that a great many bugs and build problems have been fixed. To
the many persons who offered their suggestions and fixes: thanks, we
needed that!
Anyone interested may receive source code and documentation via
anonymous ftp from CSC.TI.COM, (internet address 128.247.159.141) in
/pub/clue.tar.Z, or from EXPO.LCS.MIT.EDU in /contrib/clue.tar.Z. CLUE
7.0 will also be part of the R4 distribution of the X Window System; see
directory contrib/toolkits/clue.
Please note that CLUE 7.0 depends on R3 CLX features and bug fixes (see
R3 distribution, directory lib/CLX). The version of CLX found on
CSC.TI.COM in pub/clx.tar.Z is also sufficient to support CLUE 7.0. Be
sure to review other information found in clue/README and
clue/doc/release.7-0.
CLUE (Common Lisp User Interface Environment) is a portable system for
user interface programming in Common Lisp. CLUE, which is based on the
X Window System and the Common Lisp Object System (CLOS), extends the
CLX interface to provide an architectural model for the construction of
interactive Lisp applications. Modelled on the Xt toolkit library, CLUE
could be described as a translation of the Xt "intrinsics" into the
domain of Common Lisp and CLOS.
∂26-Sep-89 0701 CL-Windows-mailer Questions about CLX?
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Sep 89 07:01:28 PDT
Received: by ti.com id AA04403; Tue, 26 Sep 89 09:02:21 CDT
Received: from SSB by tilde id AA20055; Tue, 26 Sep 89 08:50:46 CDT
Message-Id: <2831809829-7930724@SSB>
Sender: STENGER@SSB.csc.ti.com
Date: Tue, 26 Sep 89 08:50:29 CDT
To: cl-windows@sail.stanford.edu
From: Bruce Smith <bts@cs.unc.edu>
Subject: Questions about CLX?
I have been trying to get CLX to work under KCL, on Sun3s, here at UNC, with
limited success. I have also had problems in printing the manual. Here is
how things stand, as of this weekend, along with 3 questions:
I'm working with CLX from TI.COM dated September, 1988, and a manual
dated March, 1989. I moved the relevant TCP files down into a directory named
"tcp", loaded "defsystem.l" into KCL, compiled, etc. Here's where the
unresolved problems begin:
1) With help from Dean Brock (brock@cs.unc.edu) on X and sockets
and some printf's, we found that the display number's added to
the TCP port in two places:
dependent.l, line 869:
(let ((stream (tcp:open-tcp-stream host (+ *x-tcp-port* display))))
socket.c, line 96
inaddr.sin_port = display + X_TCP_PORT;
We changed the line in dependent.l (though now I suspect that
we should've changed socket.c, instead) and were finally able
to open a window using "test/trapezoid.l", but ...
2) In "test/trapezoid.l", there are several calls to a function
called "poly-fill-Trapezoids" which does not seem to've been
defined anywhere. (Grep cannot find it in other files.)
test/trapezoid.l, line 58:
(poly-fill-Trapezoids window gc '(10 20 30 40 100 200))
I was going to write a different test function, but first I
figured I should print out the manual ...
So, in summary:
1) What's the preferred fix for the display/x-tcp-port problem?
2) Do you have a version of "test/trapezoid.l" that works?
Thanks for any answers you can provide.
__________________________________________
Bruce T. Smith bts@cs.unc.edu
Dept. of Computer Science (919) 962-1917
Sitterson Hall CB#3175
Chapel Hill, NC 27599-3175
∂26-Sep-89 0730 CL-Windows-mailer Re: Questions about CLX?
Received: from ATHENA.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 89 07:27:24 PDT
Received: from E40-381-3.MIT.EDU by ATHENA.MIT.EDU with SMTP
id AA20829; Tue, 26 Sep 89 10:29:44 EDT
Received: by E40-381-3.MIT.EDU (5.61/4.7) id AA05923; Tue, 26 Sep 89 10:27:55 -0400
Message-Id: <8909261427.AA05923@E40-381-3.MIT.EDU>
To: Bruce Smith <bts@CS.UNC.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Questions about CLX?
In-Reply-To: Your message of Tue, 26 Sep 89 08:50:29 -0500.
<2831809829-7930724@SSB>
Date: Tue, 26 Sep 89 10:27:53 EDT
From: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>
>> 1) What's the preferred fix for the display/x-tcp-port problem?
I think x-tcp-port shouldn't be hardcoded in socket.c, so
you can use the tcp interface to open any port.
>>2) Do you have a version of "test/trapezoid.l" that works?
trapezoid demo requires Zoid extension to the server.
∂26-Sep-89 1418 CL-Windows-mailer Low-level CLX tests
Received: from PROOF.ERGO.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 89 14:18:37 PDT
Received: from proof.ergo.cs.cmu.edu by PROOF.ERGO.CS.CMU.EDU id aa06967;
26 Sep 89 17:17:36 EDT
To: cl-windows@sail.stanford.edu
Reply-to: Tim Freeman <tsf@CS.CMU.EDU>
Subject: Low-level CLX tests
Date: Tue, 26 Sep 89 17:17:33 EDT
Message-ID: <6965.622847853@PROOF.ERGO.CS.CMU.EDU>
From: Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU
Here's some simple CLX test cases I came up with while trying to
understand how CLX works and to check that my window manager and CLX
implementation behaved reasonably. I haven't made a test case that
does anything with color correctly yet, I'd appreciate receiving one.
This code is in the public domain.
;;; -*- Mode: Lisp; Package: xlib -*-
;;;
;;; Trivial test file for clx.
;;;
;;; Author: Timothy Freeman. Last Modified Sat Aug 26 02:55:58 1989
(in-package :xlib) (use-package :ergolisp)
(export '(clx-test))
(defun clx-test (host)
"Do something, anything, to check that this software works at least a little bit."
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:event-mask
'(:exposure :key-press)))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground 1 :background 0)))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
(:exposure (window)
(draw-line win gcontext 0 0 100 100))
(:key-press ()
t))
(return (values))))
(close-display display))))
(defun cursor-test (host &optional (cursornum 0))
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:event-mask
'(:exposure :key-press :button-press)
:background 1))
(letter-font (open-font display "vtsingle"))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground 1 :background 0
:font letter-font))
(cursor-font (open-font display "cursor")))
(labels ((setf-cursornum (value)
(setq cursornum value)
(clear-area win)
(draw-glyphs win gcontext 0 40 (format nil "~s" cursornum))
(values)))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
(:key-press ()
t)
(:button-press
(code)
(cond
((= code 1) (setq cursornum (+ cursornum 2)))
((= code 3) (setq cursornum (- cursornum 2))))
(setf-cursornum (min 254 (max 0 cursornum)))
(let ((cursor
(create-glyph-cursor
:source-font cursor-font
:source-char cursornum
:mask-font cursor-font
:mask-char (1+ cursornum)
:foreground
(make-color :red 0.0 :green 0.0 :blue 0.0)
:background
(make-color :red 1.0 :green 1.0 :blue 1.0))))
(setf (window-cursor win) cursor)
(free-cursor cursor))
nil))
(return (values))))
(close-display display)))))
(defun configure-notify-test (host)
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:event-mask
'(:exposure :key-press
:button-press
:structure-notify)))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground 1 :background 0)))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
(:key-press (window)
(with-state (window)
(setf (drawable-width window) 100)
(setf (drawable-height
window) 100))
nil)
(:button-press (window)
t)
(:exposure (x y width height count)
(format t "Exposure, x = ~s, y = ~s, width = ~s, ~
height = ~s, count = ~s.~%"
x y width height count)
nil)
(:configure-notify (x y width height window
override-redirect-p)
(format t "Configure-notify, x = ~s, y = ~s, width = ~s, ~
height = ~s, override = ~s, window = ~s.~%"
x y width height override-redirect-p window)
nil))
(return (values))))
(close-display display))))
#|
(subwin-test "k.ergo.cs.cmu.edu")
|#
(defun subwin-test (host)
"Test that if X is a subwindow of Y and the mouse is in X and Y is unmapped,
X gets a leave-window event. This was a bug in X10. You'll have to
interrupt to get out of this function.
This function shows the bug has been fixed in X11, our version at least."
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:event-mask
'(:leave-window :enter-window)))
(win2 (create-window :parent win :x 0 :y 0 :width 50 :height 50
:event-mask
'(:leave-window :enter-window :key-press
:button-press)))
(win3 (create-window :parent win2 :x 0 :y 0 :width 25 :height 25
:event-mask
'(:leave-window :enter-window :key-press
:button-press)))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground 1 :background 0)))
(map-window win)
(map-window win2)
(map-window win3)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:enter-notify :leave-notify) (event-key x y window)
(format t "~s, x = ~s, y = ~s, win = ~s.~%"
event-key x y
(cond ((eq window win) "win")
((eq window win2) "win2")
(t window)))
nil)
((:key-press) (window)
(unmap-window win)))
(return (values))))
(close-display display))))
(defun resize-test (host)
"Verify that lowly mortals like me can use ResizeRedirect."
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:border-width 1
:event-mask '(:resize-redirect
:key-press
:button-press
:structure-notify)))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground 1 :background 0)))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press) ()
(setf (drawable-width win) 100)
(setf (drawable-height win) 100)
nil)
((:resize-request) (window width height)
(format t "Resize-request, width is ~s, height is ~s.~%"
width height)
(format t "Real width is ~s, real height is ~s.~%"
(drawable-width window)
(drawable-height window))
(let ((wor (window-override-redirect window)))
(setf (window-override-redirect window) :on)
(setf (drawable-width window) width)
(setf (drawable-height window) height)
(setf (window-override-redirect window) wor))
(format t "Real width is ~s, real height is ~s.~%"
(drawable-width window)
(drawable-height window))
nil)
((:configure-notify) (width height)
(format t "configure-notify, width is ~s, height is ~s.~%"
width height)
nil)
((:key-press) ()
(unmap-window win)
t))
(return (values))))
(close-display display))))
#|
(title-test "k.ergo.cs.cmu.edu")
|#
(defun title-test (host)
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 0 :y 0 :width 100 :height 100
:border-width 1
:event-mask '(:key-press
:button-press))))
(setf (wm-name win) "Tim's window")
(setf (wm-icon-name win) "Tim's icon")
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t))
(return (values))))
(close-display display))))
#|
(position-test "k.ergo.cs.cmu.edu")
|#
;;; Conclusion: For twm, wm-normal-hints is useless. The position
;;; and size are adjustable when the window is mapped iff the x and y
;;; are 0 and they aren't otherwise.
(defun position-test (host)
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:event-mask '(:key-press
:button-press)))
(size-hints (make-wm-size-hints :user-specified-position-p nil
:user-specified-size-p nil
:width 300
:height 400
)))
(setf (wm-normal-hints win) size-hints)
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t))
(return (values))))
(close-display display))))
;;; Does the size that TWM uses depend on the size when the window was
;;; created or the size when it's mapped?
;;; Conclusion: it uses the size when created. It even ignores
;;; resizes to the window after it is mapped unless there is a sleep
;;; between mapping and resizing.
#|
(twm-size-test "k.ergo.cs.cmu.edu")
|#
(defun twm-size-test (host)
(let* ((display (open-display host))
(screen (display-default-screen display))
(root (screen-root screen))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:event-mask '(:key-press
:button-press))))
(setf (drawable-width win) 400)
(setf (drawable-height win) 400)
(format t "Width is ~s.~%" (drawable-width win))
(map-window win)
(display-finish-output display)
(setf (drawable-width win) 400)
(setf (drawable-height win) 400)
(display-force-output display)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t))
(return (values))))
(close-display display))))
;;; Try out the colormap stuff. As a first attempt, I'll try doing
;;; the straightforward protocol requests instead of following the ICCCM.
;;; This doesn't work.
#|
(colormap-test "batcomputer.ergo.cs.cmu.edu" 1)
|#
(defun colormap-test (host &optional (screennum 0))
(let* ((display (open-display host))
(screen (nth screennum (display-roots display)))
(root (screen-root screen))
(colormap (create-colormap (window-visual root) root nil))
(pixel (elt (alloc-color-cells colormap 1) 0))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground pixel :background 0))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:colormap colormap
:event-mask '(:key-press
:button-press
:exposure))))
(format t "Pixel is ~s.~%" pixel)
(display-force-output display)
(store-colors colormap `(,pixel "Green"))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t)
((:exposure) (window)
(draw-line window gcontext 0 0 100 100)))
(return (values))))
(close-display display))))
(defun colormap-test (host &optional (screennum 0))
(let* ((display (open-display host))
(screen (nth screennum (display-roots display)))
(root (screen-root screen))
(colormap (create-colormap (window-visual root) root nil))
(pixel (elt (alloc-color-cells colormap 1) 0))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground pixel :background 0))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:colormap colormap
:event-mask '(:key-press
:button-press
:exposure))))
(format t "Pixel is ~s.~%" pixel)
(display-force-output display)
(store-colors colormap `(,pixel "Green"))
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t)
((:exposure) (window)
(draw-line window gcontext 0 0 100 100)))
(return (values))))
(close-display display))))
;;; Or maybe I should modify the root's colormap?
#|
(colormap-test-2 "batcomputer.ergo.cs.cmu.edu" 1)
|#
(defun colormap-test-2 (host &optional (screennum 0))
(let* ((display (open-display host))
(screen (nth screennum (display-roots display)))
(root (screen-root screen))
(colormap (prog1 (window-colormap root) (display-finish-output display)))
(foo (prog1 (lookup-color colormap "green") (display-finish-output display)))
(pixel (elt (alloc-color-cells colormap 1) 0))
(gcontext (create-gcontext :drawable root :function boole-c1
:foreground pixel :background 0))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:colormap colormap
:event-mask '(:key-press
:button-press
:exposure))))
(display-finish-output display)
(store-colors colormap `(,pixel ,(make-color :red 0.0 :green 1.0 :blue 1.0)))
(display-finish-output display)
(map-window win)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press :key-press) (window)
(destroy-window window)
t)
((:exposure) (window)
(draw-line window gcontext 0 0 100 100)))
(return (values))))
(close-display display))))
#|
(transient-test "k.ergo.cs.cmu.edu")
|#
;;; Does WM_TRANSIENT_FOR really work? Yup.
(defun transient-test (host &optional (screennum 0))
(let* ((display (open-display host))
(screen (nth screennum (display-roots display)))
(root (screen-root screen))
(win (create-window :parent root :x 100 :y 0 :width 100 :height 100
:border-width 1
:event-mask '(:key-press
:button-press
:button-release)))
(menu (create-window :parent root :x 10 :y 10 :width 50 :height 50
:border-width 1
:event-mask '(:button-release))))
(map-window win)
; (setf (transient-for menu) win)
(setf (transient-for menu) root)
(unwind-protect
(loop
(when (event-case (display :discard-p t)
((:button-press) (window)
(when (eq window win) (map-window menu)))
((:button-release) (window)
(unmap-window menu))
((:key-press) (window)
(destroy-window window)
(destroy-window menu)
t))
(return (values))))
(close-display display))))
∂16-Oct-89 0658 CL-Windows-mailer Please add to mailing list
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Oct 89 06:58:06 PDT
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Mon 16 Oct 89 06:59:12-PDT
Received: from hi.mcc.com by MCC.COM with TCP/SMTP; Mon 16 Oct 89 08:58:52-CDT
Posted-Date: Mon, 16 Oct 89 08:58 CDT
Received: by hi.mcc.com (5.51/ACTv4.1i)
id AA13069; Mon, 16 Oct 89 08:58:43 CDT
Date: Mon, 16 Oct 89 08:58 CDT
From: Javier B. Arellano <Arellano@MCC.COM>
Subject: Please add to mailing list
To: cl-windows@sail.stanford.edu
Cc: Arellano@MCC.COM
Message-Id: <19891016135802.5.ARELLANO@GAIA.ACA.MCC.COM>
Please add me to this mailing list.
Javier Arellano.
Arellano@mcc.com
∂17-Oct-89 1514 CL-Windows-mailer New CLX available for FTP
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Oct 89 15:14:31 PDT
Received: from OTIS.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04102; Tue, 17 Oct 89 18:15:42 EDT
Date: Tue, 17 Oct 89 18:16 EDT
From: Chris Lindblad <cjl@ai.mit.edu>
Subject: New CLX available for FTP
To: cl-windows@sail.stanford.edu, bug-clx@expo.lcs.mit.edu
Message-Id: <19891017221640.7.CJL@OTIS.AI.MIT.EDU>
There is a new version of CLX available!
It can be FTPed from the file contrib/CLX.R4beta.tar.Z on expo.lcs.mit.edu.
∂18-Oct-89 1117 CL-Windows-mailer Please put me on this list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Oct 89 11:12:05 PDT
Received: from zurich.ai.mit.edu ([18.43.0.157]) by life.ai.mit.edu (4.1/AI-4.10) id AA06892; Wed, 18 Oct 89 14:13:14 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 18 Oct 89 14:09:36 edt
Date: Wed, 18 Oct 89 14:09:36 edt
From: seth@zurich.ai.mit.edu (Seth Goldstein)
Message-Id: <8910181809.AA12703@zurich.ai.mit.edu>
To: cl-windows@sail.stanford.edu
Subject: Please put me on this list
thanks.
Seth Goldstein (seth@zurich.ai.mit.edu)
ConSolve, Inc.
∂24-Oct-89 0245 CL-Windows-mailer
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 24 Oct 89 02:45:53 PDT
Received: from unido.Informatik.Uni-Dortmund.DE by uunet.uu.net (5.61/1.14) with SMTP
id AA15397; Tue, 24 Oct 89 05:45:33 -0400
Received: from gmdzi.UUCP (gmdzi) (1199)
by unido.informatik.uni-dortmund.de
for uunet
id AK14697; Tue, 24 Oct 89 10:44:53 +0100
Received: by gmdzi.UUCP id AA13235; Tue, 24 Oct 89 10:46:34 -0100
Date: Tue, 24 Oct 89 10:46:34 -0100
From: Andreas Baecker <gmdzi!baecker@uunet.UU.NET>
Message-Id: <8910240946.AA13235@gmdzi.UUCP>
To: cl-windows@sail.stanford.edu
Please add me to the mailing list.
Thanks, Andreas.
Andreas Baecker
GMD - German National Research Institute for Computer Science
Schloss Birlinghoven
D - 5205 St. Augustin 1
West Germany
e-mail: baecker@gmdzi
∂25-Oct-89 0921 CL-Windows-mailer New CLX documentation available
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 09:21:04 PDT
Received: by ti.com id AA16824; Wed, 25 Oct 89 11:21:35 -0500
Received: from SSB by tilde id AA01490; Wed, 25 Oct 89 10:57:05 CDT
Message-Id: <2834322983-12173429@SSB>
Sender: STENGER@SSB.csc.ti.com
Date: Wed, 25 Oct 89 10:56:23 CDT
From: Dan Stenger <stenger@ti-csl.csc.ti.com>
Subject: New CLX documentation available
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
xpert@expo.lcs.mit.edu
A new, complete, up-to-date, formatted version of the documentation for CLX
(the Common LISP X Interface) is now available to the public via anonymous
ftp from
csc.ti.com (Internet address 128.247.159.141)
Anyone interested may find the documentation in the directory:
pub/clxman/
It comes in two forms. This first is Interleaf ASCII source format which is
contained in the *.doc files. The second is postscript printer format which
is contained in the *.ps files. Compressed versions of the collections of
these files may be found in the files:
pub/clxman/doc.tar.Z (Interleaf ASCII form)
pub/clxman/ps.tar.Z (postscript form)
Hopefully, this documentation will also soon be available as a part of the R4
distribution of the X Window System from the MIT X Consortium.
∂26-Oct-89 0648 CL-Windows-mailer [Re: New CLX documentation available]
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Oct 89 06:48:46 PDT
Received: by ti.com id AA25741; Thu, 26 Oct 89 08:49:23 -0500
Received: from SSB by tilde id AA26677; Thu, 26 Oct 89 08:07:28 CDT
Message-Id: <2834399207-238022@SSB>
Sender: STENGER@SSB.csc.ti.com
Date: Thu, 26 Oct 89 08:06:47 CDT
From: Dan Stenger <stenger@ti-csl.csc.ti.com>
To: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
xpert@expo.lcs.mit.edu
Subject: [Re: New CLX documentation available]
I only tested the postscript output for the new CLX documentation on TI and
Apple printers so there may be some problems on others. Not knowing much
about postscript I must rely on expert assistance. Here is a suggestion from
one person.
Dan Stenger
------- Forwarded Message
Date: Wed, 25 Oct 89 17:53:40 EDT
From: Christopher.Hoover@LISP-SUN.SLISP.CS.CMU.EDU
Subject: Re: New CLX documentation available
To: Dan Stenger <stenger@ti-csl.csc.ti.com>
Thanks for the new documentation. It looks really good so far.
Two problems:
1) All of the postscript files are missing the "%!" magic
header. This will probably confuse a lot of people.
2) Your postscript prolog needs the following:
userdict /letter known not {/letter {} def} if
so that the files will print on printers other than Apple
LaserWriter's such as DEC LPS-40's.
Thanks again,
-- Chris.
(Christopher.Hoover@cs.cmu.edu)
------- End of Forwarded Message
∂26-Oct-89 1001 CL-Windows-mailer CLX design issues
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Oct 89 10:00:54 PDT
Received: by ti.com id AA27564; Thu, 26 Oct 89 12:01:08 -0500
Received: from dsg by tilde id AA01962; Thu, 26 Oct 89 10:45:35 CDT
Received: From RIGI By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 26 Oct 89 10:43:14 CDT
Message-Id: <2834408613-15256852@RIGI>
Sender: KK@RIGI.csc.ti.com
Date: Thu, 26 Oct 89 10:43:33 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: bug-clx@expo.lcs.mit.edu, cl-windows@sail.stanford.edu
Subject: CLX design issues
Here's a list of issues previously raised by messages to bug-clx. Addressing
them may involve adding new CLX interfaces or changing interfaces now in R3.
I'm sure that other such issues exist as well.
I'm interested in starting a discussion on cl-windows that will resolve such
issues. Anyone else?
!
SYNOPSIS:
CLX should define a colormap-visual accessor to paper over a shortcoming of
the protocol.
DESCRIPTION:
After a colormap has been created, the X protocol does not allow a client to
query the server to return its visual type. But it's useful to know this
colormap attribute, since the behavior and even the validity of
alloc-color-cells, etc. depend on the class of the visual type.
FIX:
Store visual on colormap-plist when colormap is created. Define
colormap-visual accessor. Note: create-colormap also changed to accept (or
visual-info card29) for visual argument. This change should be made where
applicable in other CLX functions, so that visual-info can be used
consistently as the primary interface to visual types.
(defmacro colormap-visual (colormap)
"Access a visual-info structure on the colormap-plist."
`(getf (colormap-plist ,colormap) :visual))
(defun display-visual-info (display visual)
"Return a visual-info structure for the given VISUAL id."
(declare (type (or visual-info card29) visual)
(type display display))
(declare-values (or visual-info null))
(if (visual-info-p visual)
;; Return given visual-info.
visual
;; Else look up visual id among display screens
(block search
(dolist (screen (display-roots display))
;; Look up visual among screen depths
(dolist (depth (screen-depths screen))
(let ((visual-info (find visual (rest depth)
:key #'visual-info-id
:test #'eq)))
(when visual-info
(return-from search visual-info))))))))
(defun create-colormap (visual window &optional alloc-p)
(declare (type (or visual-info card29) visual)
(type window window)
(type boolean alloc-p))
(declare-values colormap)
(let* ((display (window-display window))
(colormap (make-colormap :display display))
(id (allocate-resource-id display colormap 'colormap)))
(setf (colormap-id colormap) id
(colormap-visual (display-visual-info display visual)))
(with-buffer-request (display *x-createcolormap*)
((data boolean) alloc-p)
(resource-id id)
(window window)
(card29 visual))
colormap))
!
SYNOPSIS:
query-best-cursor interface does not fully support the underlying
QueryBestSize request.
DESCRIPTION:
The display arg should be a drawable, since the protocol specifies that the
best (largest) cursor size may depend on the screen.
FIX:
(defun query-best-cursor (width height drawable)
(declare (type card16 width height)
(type drawable drawable))
(declare-values width height)
(let (rwidth rheight (display (drawable-display drawable)))
(with-display (display)
(with-buffer-request (display *x-querybestsize* :no-after)
(data 0)
(window drawable)
(card16 width height))
(with-buffer-reply (display 12 :sizes 16)
(setq rwidth (card16-get 8)
rheight (card16-get 10))))
(display-invoke-after-function display)
(values rwidth rheight)))
!
SYNOPSIS:
For sake of consistency with other CLX functions, should change certain
argument data types:
FIX:
(declare (type (member :on :off :default) blanking exposures))
!
SYNOPSIS:
wm-resources/set-wm-resources are inappropriate interfaces.
DESCRIPTION:
(defun wm-resources (database window &key key test test-not)
;; Takes the resources associated with the RESOURCE_MANAGER property
;; of WINDOW (if any) and merges them with DATABASE.
;; KEY is a function used for converting value-strings, the default is
;; identity. TEST and TEST-NOT are predicates used for filtering
;; which resources to include in the database. They are called with
;; the name and results of the KEY function.
(declare (type resource-database database)
(type window window)
(type (or null (function (string) t)) key)
(type (or null (function ((list string) t) boolean))
test test-not)
(values resource-database)))
(defun set-wm-resources (database window &key write test test-not)
;; Sets the resources associated with the RESOURCE_MANAGER property
;; of WINDOW.
;; WRITE is a function used for writing values, the default is #'princ
;; TEST and TEST-NOT are predicates used for filtering which resources
;; to include in the database. They are called with the name and value.
(declare (type resource-database database)
(type window window)
(type (or null (function (string stream) t)) write)
(type (or null (function ((list string) t) boolean))
test test-not)))
Problems:
1. Name is misleading. The RESOURCE_MANAGER property has little if anything
to do with window managers.
2. Interface is misleading. The RESOURCE_MANAGER property is conventionally
defined only for root windows (i.e. for screens).
3. Doesn't use setf style.
Suggest following alternative:
(defun root-resources (screen &key database convert test test-not)
"Returns a resource database containing the contents of the root window
RESOURCE_MANAGER property for the given SCREEN. If SCREEN is a display,
then its default screen is used. If an existing DATABASE is given, then
resource values are merged with the DATABASE and the modified DATABASE is
returned.
TEST and TEST-NOT are predicates for selecting which resources are
read; arguments are a resource name list and a resource value. The CONVERT
function, if given, is called to convert a resource value string to the
value given to TEST or TEST-NOT."
(declare
(type (or screen display) screen)
(type (or null resource-database) database)
(type (or null (function (string) t)) convert)
(type (or null (function ((list string) t) boolean)) test test-not)
(values resource-database)))
(defsetf root-resources (screen &key test test-not (write 'princ)) (database)
"Changes the contents of the root window RESOURCE_MANAGER property for the
given SCREEN. If SCREEN is a display, then its default screen is used.
TEST and TEST-NOT are predicates for selecting which resources from the
DATABASE are written; arguments are a resource name list and a resource
value. The WRITE function is used to convert a resource value into a
string stored in the property."
(declare
(type (or screen display) screen)
(type (or null resource-database) database)
(type (or null (function ((list string) t) boolean)) test test-not)
(type (or null (function (string stream) t)) write)
(values resource-database)))
!
SYNOPSIS:
Exposing the value-mask component of :configure-request is not the best Lisp
interface.
DESCRIPTION:
CLX programmers ordinarily don't have to know about value-masks used in the
protocol. However, a configure-window value-mask must be interpreted when
receiving a :configure-request event. This is problematic because exactly
which bit represents which geometry component is not defined even by the
protocol spec!
A better design would be to eliminate the value-mask and return nil for
unspecified components.
∂26-Oct-89 1027 CL-Windows-mailer Re: [Re: New CLX documentation available]
Received: from LISP-SUN.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 89 10:27:18 PDT
Received: from lisp-sun.slisp.cs.cmu.edu by LISP-SUN.SLISP.CS.CMU.EDU
id aa11386; 26 Oct 89 13:25:57 EDT
To: Dan Stenger <stenger@ti-csl.csc.ti.com>
Reply-To: Christopher.Hoover@CS.CMU.EDU
cc: clue-review@dsg.csc.ti.com, cl-windows@sail.stanford.edu,
xpert@expo.lcs.mit.edu
Subject: Re: [Re: New CLX documentation available]
In-reply-to: Your message of Thu, 26 Oct 89 08:06:47 -0500.
<2834399207-238022@SSB>
Date: Thu, 26 Oct 89 13:25:38 EDT
Message-ID: <11384.625425938@LISP-SUN.SLISP.CS.CMU.EDU>
From: Christopher.Hoover@LISP-SUN.SLISP.CS.CMU.EDU
>> 1) All of the postscript files are missing the "%!" magic
>> header. This will probably confuse a lot of people.
>>
>> 2) Your postscript prolog needs the following:
>>
>> userdict /letter known not {/letter {} def} if
To be more specific:
Append the following lines to the beginning of each of the postscript
files:
------------------------------ CUT HERE ------------------------------
%!
userdict /letter known not {/letter {} def} if
------------------------------ CUT HERE ------------------------------
-- Chris.
(Christopher.Hoover@CS.CMU.EDU)
∂26-Oct-89 1628 CL-Windows-mailer Serial # in events
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 Oct 89 16:28:09 PDT
Received: from Fafnir.Think.COM by Think.COM; Thu, 26 Oct 89 19:29:32 -0400
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by fafnir.think.com; Thu, 26 Oct 89 19:25:09 EDT
Received: from localhost by prometheus.think.com; Thu, 26 Oct 89 19:25:08 EDT
Message-Id: <8910262325.AA11452@prometheus.think.com>
To: cl-windows-ext@Think.COM
Subject: Serial # in events
Date: Thu, 26 Oct 89 19:25:07 EDT
From: Gary Oberbrunner <garyo@Think.COM>
In C, Xlib event structures contain a slot containing the serial number of
the last request processed by the server when that event was generated. I
use this slot in some code I have that warps the pointer, then attempts to
ignore the event generated by the warping. All this works fine in C.
My algorithm goes like this:
1. remember next event # with (xlib::display-request-number)
2. warp pointer
3. get and ignore motion events until one has a request serial # greater
than the remembered one.
I'm using this to track an external cursor with the X cursor, making the X
cursor simulate a trackball.
My problem consists of the fact that there's no CLX event slot for serial
number. I could possibly substitute timestamps, but I'd have to do a
round-trip between #2 and #3 above to get the server time (how do I even do
that??), and I'd end up throwing out even more events than I'm throwing out
now, since I'd have to throw out all the mouse events that occur between
the warp and the asking for the time.
Does anyone have any ideas on how I can:
1) get the serial number of the last processed request given an event?
or
2) find another method for doing what I need to do?
Thanks in advance,
Gary Oberbrunner
Thinking Machines Corporation
245 First St.
Cambridge, MA 02142
(617) 876-1111
garyo@think.com
∂27-Oct-89 1146 CL-Windows-mailer Re: Serial # in events
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 11:46:16 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 14:47:17 -0400
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by fafnir.think.com; Fri, 27 Oct 89 14:42:50 EDT
Received: from localhost by prometheus.think.com; Fri, 27 Oct 89 14:42:41 EDT
Message-Id: <8910271842.AA12940@prometheus.think.com>
To: oren@stroke.csc.ti.com (LaMott Oren)
Cc: cl-windows-ext@Think.COM
Subject: Re: Serial # in events
In-Reply-To: Your message of Fri, 27 Oct 89 08:03:51 -0500.
<8910271303.AA03315@stroke.csc.ti.com>
Date: Fri, 27 Oct 89 14:42:39 EDT
From: Gary Oberbrunner <garyo@Think.COM>
I'm trying to warp the pointer without getting an event for it, or at least
differentiate the warp event from a normal mouse event so I can ignore it...
LaMott suggests:
How about setting the event-mask to ignore motion events, warp the
cursor, then restore the event-mask. This way you don't have to ignore
any events.
A fine idea in theory, but in practice it doesn't work. The warp event
often slips through anyway (perhaps because it's getting merged with some
other mouse event?). So I'm stuck throwing events on the floor for a
while. Oh well. Any other ideas? :-)
- Gary O
∂27-Oct-89 1200 CL-Windows-mailer Re: Serial # in events
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 12:00:05 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 15:01:31 -0400
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 27 Oct 89 14:57:04 EDT
Return-Path: <rws@expo.lcs.mit.edu>
Received: from EXPO.LCS.MIT.EDU by Think.COM; Fri, 27 Oct 89 15:01:20 -0400
Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Fri, 27 Oct 89 14:59:15 EDT
Received: by expire.lcs.mit.edu; Fri, 27 Oct 89 14:59:11 EDT
Message-Id: <8910271859.AA08254@expire.lcs.mit.edu>
To: Gary Oberbrunner <garyo@Think.COM>
Cc: oren@stroke.csc.ti.com (LaMott Oren), cl-windows-ext@Think.COM
Subject: Re: Serial # in events
In-Reply-To: Your message of Fri, 27 Oct 89 14:42:39 EDT.
<8910271842.AA12940@prometheus.think.com>
Date: Fri, 27 Oct 89 14:59:10 -0400
From: rws@expo.lcs.mit.edu (Bob Scheifler)
I'm trying to warp the pointer without getting an event for it, or at least
differentiate the warp event from a normal mouse event so I can ignore it...
This question has come up before on xpert, but I forget exactly how I
answered it. Basically, you want to pay attention to the sequence number
in the event, and ignore the motion event that matches the sequence number of
your warp request. You may want to immediately follow the warp with another
request (e.g. a noop) to minimize getting additional motion events with the
same sequence number.
∂27-Oct-89 1726 CL-Windows-mailer Re: Serial # in events
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 17:26:37 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 20:28:05 -0400
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by fafnir.think.com; Fri, 27 Oct 89 20:23:38 EDT
Received: from localhost by prometheus.think.com; Fri, 27 Oct 89 20:23:30 EDT
Message-Id: <8910280023.AA13480@prometheus.think.com>
To: rws@expo.lcs.mit.edu (Bob Scheifler)
Cc: cl-windows-ext@Think.COM
Subject: Re: Serial # in events
In-Reply-To: Your message of Fri, 27 Oct 89 15:28:34 -0400.
<8910271928.AA08288@expire.lcs.mit.edu>
Date: Fri, 27 Oct 89 20:23:28 EDT
From: Gary Oberbrunner <garyo@Think.COM>
I wrote:
Yes, but I'm trying to do this from CLX, which doesn't allow access
to the request sequence number in the returned events.
Bob Scheifler wrote back:
Huh? It's certainly spec'd to.
Well you're absolutely right. It's not mentioned in the (just-published)
doc, but if I poke around in the source code, sure enough there it is:
"sequence" is the keyword for the request sequence number.
It now works great.
Just for your info, my delta-mouse algorithm is this:
----------------------------------------------------------------------
In grab-mouse:
-> Map the previously created input-only full-screen window
-> Grab the pointer, confined to that window.
In handle-mouse-event:
-> Get next event (compress motion here if desired)
--> When the pointer hits the edge of the window, remember SEQ#, set
warp-pending flag and warp to the middle of the screen.
--> If flag set and event seq # < SEQ#, throw event away (mouse is pinned
to edge of window).
--> If flag set and event seq# >= SEQ#, throw event away (it's the warp),
store mouse pos as 'last pos', and clear warp-pending flag.
--> Otherwise compute delta from last pos and this pos.
In release-mouse:
-> Ungrab pointer
-> Unmap IO window
----------------------------------------------------------------------
I tried all the simpler algorithms before, and this is the simplest case
that provides reasonably smooth tracking on the remote device.
Simpler algorithms usually lose because of coalescing mouse events in the
server, missed request numbers, or large mouse motions.
Thanks for your help!
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.com
∂27-Oct-89 1737 CL-Windows-mailer Bug report: no-operation is commented out.
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 17:36:35 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 20:37:56 -0400
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by fafnir.think.com; Fri, 27 Oct 89 20:33:21 EDT
Received: from localhost by prometheus.think.com; Fri, 27 Oct 89 20:33:16 EDT
Message-Id: <8910280033.AA13510@prometheus.think.com>
To: cl-windows-ext@Think.COM
Subject: Bug report: no-operation is commented out.
Date: Fri, 27 Oct 89 20:33:15 EDT
From: Gary Oberbrunner <garyo@Think.COM>
In requests.lisp, the (no-operation) function is commented out, so there is
no way to increment the server request counter or to exercise the
connection.
The comment next to the no-operation code in requests.lisp says:
#+comment ;; This is a protocol request, but its not very interesting...
!!!!! Not a very good reason to take it out!!!!
Interesting, perhaps not. Useful, definitely. Please put it back in the
next release.
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.com
∂27-Oct-89 1828 CL-Windows-mailer Doc bug report - "sequence" is not mentioned as an event keyword
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 18:28:46 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 21:30:06 -0400
Return-Path: <garyo@Think.COM>
Received: from prometheus.think.com by fafnir.think.com; Fri, 27 Oct 89 21:25:37 EDT
Received: from localhost by prometheus.think.com; Fri, 27 Oct 89 20:28:03 EDT
Message-Id: <8910280028.AA13495@prometheus.think.com>
To: cl-windows-ext@Think.COM
Subject: Doc bug report - "sequence" is not mentioned as an event keyword
Date: Fri, 27 Oct 89 20:28:02 EDT
From: Gary Oberbrunner <garyo@Think.COM>
CLX BUG REPORT
In the new, just-released CLX doc (which is wonderful!!!), there is no
mention of how to get the request sequence number that comes with an event.
In fact, it's a keyword just like display, window, x, or y. I had to look
in the source code to find it. It should be documented either at the
beginning of section 12.12, in the section on event-case, or else mentioned
with each event individually.
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.com
∂30-Oct-89 1528 CL-Windows-mailer CLX design issues
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Oct 89 15:28:20 PST
Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 271932; Mon 30-Oct-89 18:27:33 EST
Date: Mon, 30 Oct 89 18:27 EST
From: Chris Lindblad <cjl@AI.MIT.EDU>
Subject: CLX design issues
To: Kimbrough@dsg.csc.ti.com
cc: bug-clx@EXPO.LCS.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <2834408613-15256852@RIGI>
Message-ID: <19891030232732.8.CJL@OTIS.AI.MIT.EDU>
Date: Thu, 26 Oct 89 10:43:33 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
I'm interested in starting a discussion on cl-windows that will resolve such
issues. Anyone else?
SYNOPSIS:
CLX should define a colormap-visual accessor to paper over a shortcoming of
the protocol.
I think this is a fine idea. In the R4beta CLX, there is a colormap slot
called colormap-visual-info. Charlie Hornig contributed it.
SYNOPSIS:
query-best-cursor interface does not fully support the underlying
QueryBestSize request.
This sounds good too. The spec should change, but to remain compatible with
existing clients the implementation should handle a display passed to it too.
I updated the source.
SYNOPSIS:
For sake of consistency with other CLX functions, should change certain
argument data types:
(declare (type (member :on :off :default) blanking exposures))
Sounds fine too. But for compatibility, :yes and :no should be allowed too.
I updated the source.
SYNOPSIS:
wm-resources/set-wm-resources are inappropriate interfaces.
Sounds fine. For compatbility, wm-resources & set-wm-resources should be
still there, though.
I updated the source.
SYNOPSIS:
Exposing the value-mask component of :configure-request is not the best Lisp
interface.
I don't understand this enough.
∂30-Oct-89 1530 CL-Windows-mailer CLX design issues
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Oct 89 15:30:44 PST
Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 271934; Mon 30-Oct-89 18:31:19 EST
Date: Mon, 30 Oct 89 18:31 EST
From: Chris Lindblad <cjl@AI.MIT.EDU>
Subject: CLX design issues
To: Kimbrough@dsg.csc.ti.com
cc: bug-clx@EXPO.LCS.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <2834408613-15256852@RIGI>
Supersedes: <19891030232732.8.CJL@OTIS.AI.MIT.EDU>
Message-ID: <19891030233120.9.CJL@OTIS.AI.MIT.EDU>
Date: Thu, 26 Oct 89 10:43:33 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
I'm interested in starting a discussion on cl-windows that will resolve such
issues. Anyone else?
SYNOPSIS:
CLX should define a colormap-visual accessor to paper over a shortcoming of
the protocol.
I think this is a fine idea. In the R4beta CLX, there is a colormap slot
called colormap-visual-info. Charlie Hornig contributed it.
SYNOPSIS:
query-best-cursor interface does not fully support the underlying
QueryBestSize request.
This sounds good too. The spec should change, but to remain compatible with
existing clients the implementation should handle a display passed to it too.
I updated the source.
SYNOPSIS:
For sake of consistency with other CLX functions, should change certain
argument data types:
(declare (type (member :on :off :default) blanking exposures))
Sounds fine too. But for compatibility, :yes and :no should be allowed too.
I updated the source.
SYNOPSIS:
wm-resources/set-wm-resources are inappropriate interfaces.
Sounds fine. For compatbility, wm-resources & set-wm-resources should be
still there, though. [later:] For consistency, I think the name of the
CONVERT arg should be KEY, since KEY is used for other resource database
functions.
I updated the source.
SYNOPSIS:
Exposing the value-mask component of :configure-request is not the best Lisp
interface.
I don't understand this enough.
∂30-Oct-89 2132 CL-Windows-mailer CLX patch
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Oct 89 21:32:47 PST
Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 272008; Tue 31-Oct-89 00:33:28 EST
Date: Tue, 31 Oct 89 00:33 EST
From: Chris Lindblad <cjl@AI.MIT.EDU>
Subject: CLX patch
To: bug-clx@EXPO.LCS.MIT.EDU, cl-windows@sail.stanford.edu
Message-ID: <19891031053327.0.CJL@OTIS.AI.MIT.EDU>
The file expo.lcs.mit.edu:/contrib/CLX.R4beta.fix1 contains patches to the
R4beta CLX to fix an assortment of problems that have been reported. It's too
large (46KB) for me to mail out to a mailing list. Instead, as many people as
possible should ftp it. I can mail it to individuals who don't have internet
FTP access.
This patch makes the following changes in the R4beta CLX:
Fix buffer sequence reading functions reading too much.
Move some dependent code from resource to dependent.
Replace wm-resources and set-wm-resources with root-resources.
Change blanking and exposure args to set-screen-saver to :on & :off
instead of :yes and :no.
Query-best-cursor should take a drawable, not a display.
New slot visual-info for colormaps (just document it).
Keysym-index arg to keycode->keysym can't be nil.
Nil not allowed as a font arg to text-extents and text-width.
New event handler sequence functions.
Fix up the broken declare-events in doc.l.
Make the char info accessors return nil when the font or index is bad.
Uncomment out noop request.
Run test after key, not before, for read-resources.
Keysym-index arg to keycode->keysym can't be nil.
∂02-Nov-89 0134 CL-Windows-mailer Re: CLX design issues
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Nov 89 01:34:40 PST
Received: by ti.com id AA28852; Thu, 2 Nov 89 03:35:02 -0600
Received: from dsg by tilde id AA04851; Wed, 1 Nov 89 19:25:20 CST
Received: From RIGI By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 1 Nov 89 20:23:10 CST
Message-Id: <2834961834-15464989@RIGI>
Sender: KK@RIGI.csc.ti.com
Date: Wed, 1 Nov 89 19:23:54 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: bug-clx@EXPO.LCS.MIT.EDU, cl-windows@sail.stanford.edu
Subject: Re: CLX design issues
In-Reply-To: Msg of Mon, 30 Oct 89 18:27 EST from Chris Lindblad <cjl@AI.MIT.EDU>
> SYNOPSIS:
> Exposing the value-mask component of :configure-request is not the best Lisp
> interface.
>
> I don't understand this enough.
The :configure-request event is sent when redirecting ConfigureWindow
requests. The value-mask contains a 1 bit for each window geometry component
(x, y, width, height, border-width, stack-mode, above-sibling) that was
changed in the redirected ConfigureWindow request. The problem is that there's
no way specified for a CLX program to decode this bit mask.
The best solution was proposed by RWS: treat value-mask like event-mask, with
new functions (make-value-mask, make-value-keys) to convert between the
bitmask and set-of-keywords representations.
∂03-Nov-89 1309 CL-Windows-mailer Window Manager Hints (X11) for pop-up menus
Received: from postgres.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 89 13:09:18 PST
Received: by postgres.Berkeley.EDU (5.61/1.29)
id AA13607; Fri, 3 Nov 89 13:08:48 -0800
Date: Fri, 3 Nov 89 13:08:48 -0800
From: konstan@postgres.Berkeley.EDU (Joe Konstan)
Message-Id: <8911032108.AA13607@postgres.Berkeley.EDU>
To: cl-windows@Sail.Stanford.EDU
Subject: Window Manager Hints (X11) for pop-up menus
We are trying to implement pull-down and pop-up menus using clx under
X11R3. The window manager (TWM) is putting title bars on them which
we would prefer to avoid. Are there WM-hints we can specify to the window
managers to request that menus (which are children of the root window) be
completely left alone? Also, are these TWM-specific, and is there a set of
standard window-manager hints which will work under all WMs?
Thanks for any help.
Joe Konstan
konstan@postgres.berkeley.edu
∂04-Nov-89 1319 CL-Windows-mailer Window Manager Hints (X11) for pop-up menus
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Nov 89 13:19:19 PST
Received: from OTIS.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA06363; Sat, 4 Nov 89 16:19:16 EST
Date: Sat, 4 Nov 89 16:20 EST
From: Chris Lindblad <cjl@ai.mit.edu>
Subject: Window Manager Hints (X11) for pop-up menus
To: konstan@postgres.berkeley.edu
Cc: cl-windows@sail.stanford.edu
In-Reply-To: <8911032108.AA13607@postgres.Berkeley.EDU>
Message-Id: <19891104212016.5.CJL@OTIS.AI.MIT.EDU>
Date: Fri, 3 Nov 89 13:08:48 -0800
From: konstan@postgres.berkeley.edu (Joe Konstan)
We are trying to implement pull-down and pop-up menus using clx under
X11R3. The window manager (TWM) is putting title bars on them which
we would prefer to avoid. Are there WM-hints we can specify to the window
managers to request that menus (which are children of the root window) be
completely left alone? Also, are these TWM-specific, and is there a set of
standard window-manager hints which will work under all WMs?
Have you tried specifying :override-redirect t when you create the windows?